My company distributes an application with a background service component that sends and receives mail from a single email account using SMTP/POP3.
The app uses basic authentication, but we need to implement OAuth 2.0 now due to Microsoft's planned rollback of basic auth for POP3 (and likely SMTP in the future). We have been investigating the account setup and API permissions necessary to achieve this in Azure AD.
Our current understanding is that it is possible to implement the 2-legged client credentials flow by getting an access token and then sending requests to the Graph API (eg. https://graph.microsoft.com/Mail.ReadWrite). However, our application is built to send and receive with the legacy SMTP/POP3 protocols and changing the mail features to send HTTP requests to the Microsoft API endpoints requires a partial redesign.
It appears that only 3-legged flows are supported for the legacy SMTP and POP protocols. These permissions are only available as "delegated permissions" on the Graph API. There are no equivalent "application permissions" that would allow us to use these protocols from our background service without a user present to do the initial authentication.
Integrating a browser redirect into the app for the initial authentication also requires a significant update to the application. The app is 14 years old and the original programmer is no longer at the company. Due to that fact as well as limited resources, we're hoping for a solution that doesn't involve implementing browser integration or major changes to the sending and receiving functions.
Is it possible to implement a 2-legged OAuth flow to authenticate an account for sending and receiving over SMTP/POP3?
Might any of our assumptions be incorrect?
No. It's impossible.
OAuth access to IMAP, POP, SMTP AUTH protocols via OAuth2 client credentials grant flow is not supported.
Currently the supported flows are:
OAuth2 authorization code flow
OAuth2 Device authorization grant flow
See details here.
If you have this requirement, you can post your idea on Microsoft Graph user voice.
Related
Consider that we have:
An SPA or a statically generated JAMStack website.
A REST API.
The website is being served with nignx that also reverse proxies to our API.
--
It is required that a user should be able to register/authenticate with an identity provider (say, Google) through the OpenID Connect protocol. For the sake of simplicity, let us assume that the user has already registered with our API.
Talking about authentication using OIDC, from what I have read on the subject, the steps you take are the following:
Register the application with the IdP and receive a client id and a secret.
When the user initiates a login (with Google) request on the API ('/api/loginWithGoogle') the API sets a state variable on the request session (to prevent CSRF) and redirects the user-agent to the IdP's login page.
At this page, the user enters their credentials and if they are correct, the IdP redirects the user to the callback URL on the API callback (/api/callback).
The request received on the callback has the state parameter (which we should verify with the one we set on the session previously) and a code parameter. We exchange the code for the identity token with the authorization server/IdP (we also receive access/refresh tokens from the auth server, which we discard for now because we do not want to access any APIs on the behalf of the user).
The identity token is parsed to verify user identity against our database (maybe an email).
Assume that the identity is verified.
-- The next part is what's giving me trouble --
The documentation that I have read advises that from here we redirect the user to a URL (e.g. the profile page)and start a login session between the user agent and the API. This is fine for this specific architecture (with both the SPA/static-site being hosted on the same domain).
But how does it scale?
Say I want to move from a session based flow to a JWT based flow (for authenticating to my API).
What if a mobile application comes into the picture? How can it leverage a similar SSO functionality from my API?
NOTE: I have read a little on the PKCE mechanism for SPAs (I assume it works for JAMStack as well) and native mobile apps, but from what I gather, it is an authorization mechanism that assumes that there is no back-end in place. I can not reconcile PKCE in an authentication context when an API is involved.
Usually this is done via the following components. By separating these concerns you can ensure that flows work well for all of your apps and APIs.
BACKEND FOR FRONTEND
This is a utility API to keep tokens for the SPA out of the browser and to supply the client secret to the token service.
WEB HOST
This serves unsecured static content for the SPA. It is possible to use the BFF to do this, though a separated component allows you to serve content via a content delivery network, which some companies prefer.
TOKEN SERVICE
This does the issuing of tokens for your apps and APIs. You could use Google initially, though a more complete solution is to use your own Authorization Server (AS). This is because you will not be able to control the contents of Google access tokens when authorizating in your own APIs.
SPA CLIENT
This interacts with the Backend for Frontend during OAuth and API calls. Cookies are sent from the browser and the backend forwards tokens to APIs.
MOBILE CLIENT
This interacts with the token service and uses tokens to call APIs directly, without using a Backend for Frontend.
BUSINESS APIs
These only ever receive JWT access tokens and do not deal with any cookie concerns. APIs can be hosted in any domain.
SCALING
In order for cookies to work properly, a separate instance of the Backend for Frontend must be deployed for each SPA, where each instance runs on the same parent domain as the SPA's web origin.
UPDATE - AS REQUESTED
The backend for frontend can be either a traditional web backend or an API. In the latter case CORS is used.
See this code example for an API driven approach. Any Authorization Server can be used as the token service. Following the tutorial may help you to see how the components fit together. SPA security is a difficult topic though.
The architecture of the system is like this
User can log into the website using either username-password approach (after registration) or a google-sign-in.
I want to know how can I implement authentication and authorization for this scenario.
Here is what I am thinking of implementing :
Have an REST API server built over NodeJS and Express.
The login and registration processes are handled by this server as well.
The authentication is done by using JWT Tokens stored in the client side. And these tokens are then used again for authorization of endpoints as well.
How much secure is this approach? And how can google sign in be added to this architecture.
And also if a seperate server for making auth requests is needed as mentioned in OAuth 2.0?
It would be better if the system remains Stateless to follow the principles of RESTFul APIs.
This post that I have written might give you some insight.
https://dev.to/ralphwjz/login-management-for-spa-and-everyone-else-12o6
The post covers Github login but if you replace GitHub with google, the rest of the flow is exactly the same.
I can answer more questions once in context
How can I authenticate my mobile app(flutter) against social providers while using a flow provided by an IdentityServer4 system?
I'm trying to build a mobile app which will authenticate a user via Azure AD b2c. This question will be valid for any provider of an IdentityServer4 service though. For mobile apps, everything I read suggests using the Resource Owner Password Credentials(ROPC) flow. My understanding is that ROPC does not allow for social providers to be authenticated with. Is there an alternative flow to use specifically for social providers authentication? Is my understanding of ROPC wrong? I know mobile apps can authenticate with social providers, I've seen enough do it.
If you want to authenticate social providers and the users of mobile application, you could use auth code flow via Azure AD B2C. You can use it for authentication and authorization in most application types, including web applications and natively installed applications.
About Resource Owner Password Credentials (ROPC) flow, more secure alternatives are available and recommended. This flow requires a very high degree of trust in the application, and carries risks which are not present in other flows. You should only use this flow when other more secure flows can't be used. It is not recommended.
Update:
How does the auth code flow work for mobile authentication when it needs a redirect uri to send the resulting token to? This seems similar to the implicit flow for websites.
They are similar, but they apply different application types. You could learn more about the flow(auth code flow, implact flow). The docs are about AzureAD, but the processes are the same as B2C.
The protocol diagram of auth code flow is this:
The protocol diagram of implicit flow is this:
I am looking to allow a user to sign in with github for a website I am creating that will be API driven. However, I am running into a problem that there seems to be no way of authenticating a user and getting their email and name without redirecting them on the current page to github. I have tried to create a popup, but there is no way for me to get the necessary data from the popup, namely an api token to be used for the next calls.
The answer to the question as framed is "use a different grant flow" but your questions tell me you don't understand OAuth grant flows so you may be better served by a lecture on OAuth.
Popups and iframes are specifically designed to prevent code running outside them from fishing out data, because if you could do it so could invisible iframes in dodgy ads. Give up on that approach because in the unlikely event that you find a way, browser makers will immediately take steps to prevent your solution from working.
The behaviour you describe sounds to me like implicit grant flow.
Here's a walkthrough of the various ways OAuth2 can work.
Why so many ways?
Implicit grant is a flow that uses redirection to deliberately take control away from your code - which might be compromised or impersonated - and give it to a trusted third party, the OAuth provider: GitHub in this case. You pre-register the point to which control is returned after authentication, the point of which is the token is always given to your code.
Amnesia, popups, and what was I doing before we were so rudely interrupted?
There are flows that use popups. Usually this is the authorisation code grant flow. Popups are not suitable for mobile devices and this led to the creation of the implicit grant flow.
The usual reason for not liking redirection is the amnesia it causes. The solution is to store app state persistently prior to passing control to the OAuth provider, and to write a return-from-oauth handler that unpacks the JWT from the redirect parameter and then restores the app state you saved.
Note to self
If the user is anonymous prior to authentication serialise your state to a string and put it in a cookie or in localStorage.
If the user is not anonymous and is authenticating to elevate privilege you'll have to send any privileged data to the server and just persist a retrieval token on the browser. You must ensure that retrieval of this state requires both a valid OAuth token and a valid state token, and that it discards the state after honouring a request so that a replay attack will be conspicuous (you'll have to handle the fallout).
Having acquired a valid token you can use it to request profile information from GitHub. A very small amount may already be present in the JWT; you'll probably have the email address that served as a login, but this isn't necessarily the right one for correspondence.
GitHub OAuth documentation
It appears GitHub only supports code grant auth. That means you have to do the popup/iframe thing. Here's their doco:
https://developer.github.com/v3/oauth/
Code grant - why?
This flow doesn't give you an encoded token, it gives you a code you can redeem for an encoded token. The idea is that when the token expires you can use the code to get a refresh token without sending credentials over the wire.
Not only you have a redirection, but starting Dec. 2020, you also have:
OAuth 2.0 Device Authorization Flow now GA
GitHub Apps and OAuth Apps now feature GA support for the OAuth 2.0 Device Authorization Grant, in addition to the existing Web Application Flow.
This allows any CLI client or developer tool to authenticate using a secondary system with a browser.
GitHub CLI uses this authentication method on the login command.
Read the full documentation on Authorizing OAuth Apps and Authorizing Users for GitHub Apps for more information.
Confirmed March 2022:
Enable OAuth Device Authentication Flow for Apps
From today the OAuth Device Authorization flow feature must be manually enabled for all OAuth and GitHub Apps.
This change reduces the likelihood of Apps being used in phishing attacks against GitHub users by ensuring integrators are aware of the risks and make a conscious choice to support this form of authentication.
If you own or manage an OAuth App or GitHub App that makes use of the OAuth Device Authorization flow, you can enable it for your App via its settings page:
The OAuth Device Authorization flow API endpoints will respond with status code 400 to Apps that have not enabled this feature.
Documentation: "Device flow"
When using User-agent flow with OAuth2 for mobile platform, there is no way for Authorization server to authenticate the client_id of the application.
So, anyone can impersonate my app by copying the client_id (and so get all access tokens on my behalf), and this is applicable to Facebook, Foursquare,...
This is not managed by OAuth2 ? Or I missed something ?
For Web applications (Web server flow), access token is stored on the server side, and the client is authenticated using secret key.
There's no good answer. Native app callbacks typically happen via custom registered URI schemes (e.g.: callback redirection URI is something like: myapp://oauth?code=xyz123). Unfortunately, any app can claim ownership of a given protocol scheme and receive the callback.
This problem is very synonymous with trying to lock down any protocol with "trusted clients". Think of the IM networks battle to lock out 3rd party clients (in early 2000's). Eventually they gave up - since whatever client & protocol endpoints are deployed could be reverse engineered by 3rd party developers.
Note: There is also some active discussion on this topic on the OAuth WG mailing list: http://www.ietf.org/mail-archive/web/oauth/current/msg08177.html
Normally client_id is associated with site's URL - OAuth responses/redirects will be sent only to the registrated Url. So attacker will not be able to receive results of the request on own site (unless somehow your and attacker pages are on the same domain).