https://developer.microsoft.com/en-us/office/blogs/end-of-support-for-basic-authentication-access-to-exchange-online-apis-for-office-365-customers/
Our organization is finding this announcement somewhat problematic! We use an IMAP library extensively to read various service based email accounts in o365. Any guidance on how to address this would be greatly appreciated.
Note, we have many console apps written in .NET (4.8) that run on a server based fired by many scheduled tasks. I understand we'd need to somehow register our "application" (I'm assuming that can be a generic one for our company), but we cannot involve any "user" interaction. These are utility apps. Glancing at the existing sample code for OAuth, they all seem to involve popping up a browser window to get someone to interact with "asking permission" which is exactly what we need to avoid.
We've used IMAP all this time to simply read and parse service based email accounts. I'm not sure I understand why IMAP over a secure connection is "less secure" than a more complex solution. Why take the option away?
On the other hand, the Microsoft Graph API looks significantly more complicated and appears to be OAuth based which, again, seems to involve quite a bit of authentication complexity.
Most REST APIs we've interacted w/ in other .NET console apps use a simple set of API "keys." Why not offer that at least?
As I say, we're looking for a way to write some process that run programmatically to automate a number of operations related to certain mailboxes. IMAP has worked like a charm so far, so we're looking for direct guidance on what to migrate to.
We understand your concerns. While a secure IMAP connection protects the data that's being transported, Basic Authentication exposes your Exchange Online accounts to attack techniques like phishing or brute forcing.
The primary objective of this change is to protect our customers from these threats. In addition, Modern Auth enables admin visibility into app access and enables fine-grained control of these apps.
To answer your question on implementation guidance, there is an existing approach in Graph to achieve exactly what you're looking to do. It's called "OAuth 2.0 client credentials flow". You can read more at https://learn.microsoft.com/en-us/graph/auth-v2-service
(Disclosure - I'm a Senior PM at Microsoft)
Related
So I have been looking into OAuth lately, I want to authorize another of my domain which has separate database using OAuth. Upon searching I found auth0.com. Which sounded similar to Oauth and I created a sample implementation, it offers support for custom databases also. We have users stored in external api running on .net core, and I learnt that auth0.com is not free after trial expiration. So my efforts kindof got wasted. Now I am looking for authorization method that works for both domains.
Now my question is, does it even make sense to use Oauth for this task? Since I won't be giving it to third party and it's matter of two databases. How should i approach this and what are opensource Oauth services that allow custom database.
I am trying to configure a mailbox on Exchange Online to be used by our Deskpro ticketing system to manage several queues. The only way I could setup Deskpro to recognise different folders in the mailbox was to make the connection using EWS. MS said they would be deprecating EWS Basic Auth in October last year, does that mean my EWS connection via outlook.office365.com/EWS/Exchange.asmx is now authenticating through OAuth? It still works, I'm concerned MS will change something and it'll stop working.
I'd love to use the OAuth via Graph, but if I select that option in the Deskpro setup there's no way to identify individual folders for each queue to process meaning I'd have to have a separate mailbox for each queue requiring an Exchange Plan license for each!
Collin, yes there is an announcement made to deprecate EWS Basic auth (it was made quite some time earlier too) and move to modern auth/oAuth too - it will work for you. Also you know that no new investments are going to be made in EWS, so you wont get any new features. So keeping in that mind, you can use EWS modern auth/oAuth for a while, but i would recommend you to create plan to move to Microsoft Graph API - so that you can interact with all the existing features in EWS and connect with entire Microsoft Graph ecosystem's product/solutions as well.
I am creating a new React SPA. Users of a legacy app need be able to use the new app without re-authenticating. So I need to support SSO.
It's important to note that it is also required that users of other (currently unspecified) apps should also be able to use the new app without re-authenticating, so whatever approach I take needs to be sufficiently decoupled to potentially allow this.
The legacy app supports authentication via Shibboleth, the new app currently has no authentication method, but uses JWT for authorisation.
I'm wondering if anyone has any experience of such a scenario? It seems to me that I probably need to be create an OAuth2 authorisation server for the new app to talk to and I need to somehow bring Shibboleth into the mix for the authentication, maybe with the authorisation service acting as a Shibboleth Service Provider. Googling around hasn't revealed much useful info.
Is what I've described along the right lines? I know it's very high level and woolly, but I'm really not sure of the approach to take. Any advice, information or experience in this area would be gratefully received!
GOALS
It's a little bit of a subjective question, but the main goals are usually as follows:
Focus on building your UI and API security in a future facing manner
Also provide good Login Usability
Also deliver on non functional requirements such as availability / reliability
AUTHORIZATION SERVER
On the first point, the modern option is to integrate UIs and APIs with an Authorization Server - perhaps as in My Tutorial. Your architecture is then good, but the migration is not trivial.
FEDERATING TO SHIBBOLETH
The Authorization Server can then redirect to Shibboleth and talk SAML2.0 to achieve Single Sign On, as you suggest. It is a complex solution though, and may be a backwards step in some ways.
AVAILABILITY
This is usually a big concern, and most companies use a cloud provider such as Azure / AWS due to its high availability / low maintenance / low cost. Would this be a better option for you?
I'm working for a non-profit that is trying to create a collection of services that will allow them to do a few things:
Create/Manage Users
Create/Manger Competitions
Create/Manager Events(a Competition is made up of many Events)
Logistics
Etc.
Here are some of the requirements:
Host on Azure
Accounts are created using the user's own email address (can be any domain)
Each service must be independent of each other
System should be accessible from anywhere(browser, mobile app, etc.)
Once a user logs in, access to other systems should be available(if needed or depending on permissions)
-services can talk to each other(we've successfully done a POC on this using Azure Active Directory)
I've spent some time researching the possible ways to tackle this, including looking at articles like this:
http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/
It sounds like JWT is the way to go, but I want to make sure that this architecture approach lends itself to flexibility down the road. I'm willing to learn/user any technology as long as it plays along .Net, Web Api, and MVC.
My initial idea was to set each "system" as a Web API, which is pretty straightforward. My concern is authentication/authorization. The million dollar question then becomes:
How can I authenticate a user on a browser/mobile/desktop app and then make use of the other services(APIs), where each service can verify if the user is authenticated independent of other services.
For example, lets say I am using the web app(browser) and register as a user(using User service) in order to register for a competition(Competition service). what kind of technologies/architecture would need to be used for both services to use the same authentication mechanism?
I am not new to MVC or Web API but I am to a scenario like this, so all help or advice is greatly appreciate it. For any that are interested, this is the non-profit: http://worldjumprope.org/
They are doing some cool stuff in terms of outreach and spreading the love for jump rope. Their goal is to be able to help people all around the world and provide a way to for them to come together and compete. They've been doing it for years, growing each year, all for free and out of pure passion for the sport. Help me help them!
Azure Active Directory can help you with your need.
About the security/Auth mechanism, simply put, it is like you get a token from Azure Active Directory to be able to use it to do authentication for a certain Audiences/Tenants.
And in your architecture, when you acquire a Token, you can specify if you are going to use it against a certain audience or it will work for a list of audiences or all audiences in a specific tenant or in a multi tenant scenario.
Here is a link to a video about AAD Single Sign on:
https://azure.microsoft.com/en-us/documentation/videos/overview-of-single-sign-on/
You can download the AAD Solutions arcutecture from here:
http://www.microsoft.com/en-us/download/details.aspx?id=45909
Also maybe worth looking at Identity Server - https://github.com/IdentityServer/IdentityServer3.
Same concept as Azure AD in terms of tokens, but perhaps with greater options for what you choose as a data store for your user information.
There are lots of demos and source code on the site, particularly around the different types of authentication flow \ service to service authentication
I'm starting a new system creating using .NET MVC - which is a relatively large scale business management platform. There's some indication that we'll open the platform to public once it is released and pass the market test.
We will be using ExtJs for the front-end which leads us to implement most data mining work return in JSON format - this makes me think whether I should learn the OAuth right now and try to embed the OAuth concept right from the beginning?
Basically the platform we want to create will initially fully implemented internally with a widget system; our boss is thinking to learn from Twitter to build just a core database and spread out all different features into other modules that can be integrated into the platform. To secure that in the beginning I proposed intranet implementation which is safer without much authentication required; however they think it will be once-for-all efforts if we can get a good implementation like OAuth into the platform as we start? (We are team of 6 and none of us know much about OAuth in fact!)
I don't know much about OAuth, so if it's worth to implement at the beginning of our system, I'll have to take a look and have my vote next week for OAuth in our meeting. This may effect how we gonna implement the whole web service thing, so may I ask anyone who's done large-scale web service /application before give some thoughts and advice for me?
Thanks.
OAuth 1 is nice if you want to use HTTP connections. If you can simply enforce HTTPS connections for all users, you might want to use OAuth 2, which is hardly more than a shared token between the client and server that's sent for each single request, plus a pre-defined way to get permission from the user via a web interface.
If you have to accept plain HTTP as well, OAuth 1 is really nice. It protects against replay attacks, packet injection or modification, uses a shared secret instead of shared token, etc. It is, however, a bit harder to implement than OAuth 2.
OAuth 2 is mostly about how to exchange username/password combinations for an access token, while OAuth 1 is mostly about how make semi-secure requests to a server over an unencrypted connection. If you don't need any of that, don't use OAuth. In many cases, Basic HTTP Authentication via HTTPS will do just fine.
OAuth is a standard for authentication and authorization. You can read about it in many places and learn; Generally the standard lets a client register in the authentication server, and then whenever this client attempts to access a protected resource, he is directed to the auth-server to get a token (first he gets a code, then he exchanges it with a token). But this is only generally, there are tons of details and options here...
Basically, one needs a good reason to use oAuth. If a simpler authentication mechanism is good for you - go for it.