Referred https://msdn.microsoft.com/en-us/office/office365/api/use-outlook-rest-api.
Still I couldn't understand the AD, Outlook and windows live.
I got refresh token and access token from https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token
and the scope
openid email profile offline_access
https://outlook.office.com/mail.send
https://outlook.office.com/mail.readwrite
Still i m getting error while connect imap using the access token.
imap.authenticate('XOAUTH2', 'xxxxxxx', access_token)
Net::IMAP::NoResponseError: AUTHENTICATE failed.
I have finally gotten this to work.
Interestingly I had to use the scope https://outlook.office365.com/IMAP.AccessAsUser.All although by now you have to register your app under the Graph API section in the Azure AD and the proposed Scope is https://graph.microsoft.com/IMAP.AccessAsUser.All which did not work for me (Authentication failed).
Though I am not sure if that will change in the near future.
I used the properties as stated here: https://javaee.github.io/javamail/OAuth2
props.put("mail.imap.sasl.enable", "true");
props.put("mail.imap.sasl.mechanisms", "XOAUTH2");
props.put("mail.imap.auth.login.disable", "true");
props.put("mail.imap.auth.plain.disable", "true");
For those asking about IMAP for personal accounts -- Outlook.com
-- re: comment
Apparently the scopes for the consumer Outlook.com (also live.com) is wl.imap.
See old Microsoft doc on Scopes and permissions.
Update: see also newer Microsoft doc Using Windows Live scopes and Outlook REST API to access Outlook.com mailbox data
Also have a look at this example where the same scope is mentioned:
http://afterlogic.com/mailbee-net/docs/OAuth2MicrosoftRegularAccountsInstalledApps.html
BTW, we came across the old Microsoft doc from Clever Components article:
https://www.clevercomponents.com/articles/article049/
note: their claim this is for Office365 may be questionable, perhaps a documentation error on their part
which has a link to a Microsoft doc:
https://msdn.microsoft.com/en-us/windows/desktop/dn440163
which has a link to Scopes and permissions in the related section listed at the end of the page:
https://msdn.microsoft.com/en-us/windows/desktop/hh243646
In the Clever Components article, they used two scopes wl.imap and wl.offline_access.
They noted that:
Microsoft recommends to use the "wl.offline_access" scope together with "wl.imap". Otherwise, an app can access the user's info only when a user signs in to Live Connect and uses your app."
So if your application needs continuous access then you need to include the offline access scope.
See latest Microsoft announcement on April 30, 2020.
Announcing OAuth 2.0 support for IMAP, SMTP client protocols in Exchange Online
Today, we’re announcing the availability of OAuth 2.0 authentication for IMAP, SMTP AUTH protocols to Exchange Online mailboxes.
Related
I'm supporting an installed application, a standalone desktop application. I would like to enable people whos use this application to send out emails using their Yahoo email account.
I know that I will need to create an application in Yahoo Developer Network, then generate a URL to request a Yahoo OAuth2 token first and then use this token, I can use SMTP or OpenID API to send out emails.
I've encountered a lot of problems while creating my application in Yahoo Developer Network, and requesting the token. I've compiled them and I'm listing them below:
Confidential client or public client:
Yahoo explains that one should choose confidential client for traditional web application and choose public client for mobile apps, native apps, or single-page apps.
If confidential client is selected, there will be client secret generated; and if public client is selected, there will be no client secret generated. Plus, if I choose public client, which I did for my application, when I request OAuth2 token, I can choose to not include client secret as one of the parameters and it looks like that that is not causing any problem.
API Permission:
I took it as scope. But the strange thing is that it does not include anything like Google. Google states "Send email on behalf of customer", but similar choice in Yahoo is like OpenID Connect Permissions-Email, which has a brief introduction as "Access to email address and verified status".
There is another possible choice for OpenID Connect Permissions, as well. It's called Profile, having a brief introduction as "Access to common profile information (eg. first/last name, gender, etc.)".
Another strange thing about permission is that when I started to request OAuth2 token by opening a generated request url, after logging into my yahoo account, the page stated the permission as "Read Profile", which does not meet our expectation, as I took it. Plus, it does not have anything like sending email on behalf of customer.
Redirect URI:
In Yahoo developer center, for the application I created, I set it to localhost, port 55555, the same as I set for Google OAuth2.
I have reviewed some code examples, the code uses the secret, the stuff that only exists for confidential clients, or traditional web application, and stated that I need to develop a redirect web page in our website, which redirects to localhost, port 55555.
Redirect URI is also a required parameter when generating the OAuth2 token request url. If I state localhost as the redirect uri inside the requesting url, Yahoo page says "Oh, no. There had been some problems, please try again. Developer: Please send a valid request."
If I set the redirect uri to "oob", which means "out of boundary", as stated in Yahoo OAuth2 Guide, the generated url will succeed, but the same page shows up again after I login to my Yahoo account and grand the permission requested. Well the permission is also wired. It's "Read Profile", nothing about email sending.
I have searched Internet to find out what exactly those settings should be set for my scenario and read thoroughly through Yahoo OAuth2.0 Guide. But nothing is clear enough for me to do my coding job. Could anyone shield some light for me? Thanks in advance.
Plus, I'm thinking of getting help from Yahoo regarding this task, but it seems that they do not have any communication channels for developers like me. Anyone knows more about that and would like to share with me? Thanks, again.
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.
I've been using the plus.people.get Google method with an OAuth2 bearer token in order to fetch the user's email address after an OAuth2 login. That endpoint will be shut down in March, with 'intermittent errors' starting at the end of January.
I can't seem to find an equivalent endpoint that allows me to exchange an OAuth2 token for the user's email address with no, or minimal, additional scope. All the (numerous) answers I've come across on SO are out of date due to the deprecation, there's no replacement APIs listed in the shutdown announcement, and so far I've not found a functionally equivalent Google API.
The Gmail profile API will allow email retrieval, but the minimal scope allows reading the user's email. I don't want to require my users to have to approve that for obvious reasons.
Sorry if this is a duplicate, but I'm unable to find anything helpful so far.
EDIT: of course directly after posting I found the people API.
Authorize the scope https://www.googleapis.com/auth/userinfo.email and call the Google OAuth2 API endpoint (oauth2 v2) userinfo.v2.me.get if you are using a library or directly to https://www.googleapis.com/userinfo/v2/me with the authentication.
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"
Use-case: Emails to be sent from a web-application upon an event, as someuser#somedomain.com via MS Exchange or Outlook.com, using the RESTful APIs exposed by Outlook.com. Only HTTP access allowed (=> no SMTP/IMAP).
All documentation seems to mention that the app has to forward users to MSOnline, sign-in and then use the authorization code sent back by MS online.
But, this won't work for a background task (=> no sign-in possible!) where a pre-built token(with some predefined scope) is necessary so that Outlook.com can be accessed via APIs to send mail as someuser#somedomain.com.
Any hints/pointers to how it could be done? Basically, automated authentication without explicitly signing in as 'someuser#somedomain.com' on the MS Online login page.
I did not find M$ documentation regarding Outlook REST APIs to be of any great help and found it to be pretty difficult to navigate/understand. :(
Thanks!
At some point you will have to have the user sign in to grant access to your app. So you would need to have some sort of user-facing web front end where they can do this. Once they have signed in and you've obtained an access token/refresh token, your background app should be able to use those tokens silently, without user interaction, at least until the user either revokes access or the refresh token expires.
Currently Azure (which provides the login/token functionality) does expire the refresh tokens after some time (90 days), at which point the user must sign in again to grant your app continued access.