Background
We have a feature that syncs calendar entries and contacts between our application and Office365, using the Office365 REST apis outlined here. We are using Version 1 of the API. For authorization we are performing authorization via Azure AD as outline here.
Problem
In the normal case (when using Office365 accounts purchased directly from Microsoft), our system works as expected: we are able to refresh the user's tokens when they expire and are returned a new access and refresh token in exchange.
In the second case, when testing with Office365 accounts purchased via GoDaddy, we encounter a blocking issue that can be outlined in this series of steps:
1. User is sent from our app -> Office365 Login page.
2. User enters email address
3. User is redirected to GoDaddy Office365 login page.
4. User completes authorization, and is redirected back to our app with an access code in the response.
5. App exchanges access code for an access_token and refresh_token from Office365.
6. Some time goes by, and access_token expires
7. App refreshes the user's access_token using the refresh_token
Expected Behaviour
At this point we are expecting to receive a new access_token as well as a new refresh_token, as we do when using a regular Office365 account
Actual Behaviour
Only for accounts purchased via GoDaddy, we do not receive a new refresh token in the response after refreshing for the first time.
Obviously when intending to have a long-running sync, this is a breaking case as the user will no longer be able to have their tokens refreshed beyond this point.
Postman traces (can save as .json and import to Postman for debugging
https://gist.github.com/drunkel/7ec66ed33f66d0070148694651699d03 (IDs and secrets have been removed)
Question:
Is this a known issue?
Is there a workaround?
I am a Software Engineer at GoDaddy and can confirm that this issue has been resolved. The reason for more frequent login requests under Modern Authentication is that as these are federated users and as you mentioned in your question, the refresh token was not being returned. This was caused by the StsRefreshTokensValidFrom attribute on the AAD user not being updated properly.
Every provider can decide how to implement its own oAuth server with certain policies on how to act with certain grant type and policies about granting/revoking refresh tokens/id tokens/access token and their lifetime properties.
This is a known issue with go daddy when purchasing office 365 accounts. see here and also here and here.
So it seems like GoDaddy decided to implement their OAuth server with a restricted security policy about refresh tokens by not enabling and not sending back a refresh token to the API calling the OAuth authentication and authorization when you purchase office 365 accounts through GoDaddy.
This is security enhancement/block to disable your application not to hold a lifetime refresh token that can be lived forever (if refreshed) to these office 365 accounts purchased on Godaddy
Usually, OAuth servers implemented with integration with Azure Active directory have the following token lifetime (but you can change and decide to override configure them differently 3rd party implement their own server with their own policies about tokens)
Another important featurw which Go Daddy does not support multi-factor authentication(mfa) for office 365 accounts found here.
Azure lifetime policies:
Azure Active Directory Configurable token lifetime properties
Another important issue is that if you want to be able to continue to refresh the token while the user is offline you must ask the user for access_type="offline", so during a time of inactivity from the user, you can continue to refresh the token and to hold long lifetime token for the account.
If the user decides to revoke the token for any reason - the token immediately expires.
Another issue in the steps you described is:
User is sent from our app -> Office365 Login page.
User enters email address
The user is redirected to GoDaddy Office365 login page.
so now the refresh token for office 365 flow from server to the hands of Godday servers.
User completes authorization and is redirected back to our app with an access code in the response. (but without the refresh token obtained the in the last server to server step. Godaddy to keep security on behalf of 365 accounts keeps it to itself and not returning it to the end user.
The app exchanges access code for an access_token and refresh_token from Office365. 6. Some time goes by, and access_token expires 7. App refreshes the user's access_token using the refresh_token
Related
I am struggling to get access tokens from .net console app context. I am getting them and they work, but they expire too fast.
I checked the other two threads in stackoverflow, in both answers it was stated, that once you get the consent per IK and per user, you don't have to do it anymore. However once I get the bearer token from the return_url and use it to request the access tokens a few minutes after the bearer was obtained, I get response with "error_description:expired_client_token".
So me manually obtaining bearer from the browser in order to set it as a parameter (again manually) in my console app and having the bearer expiration duration just a few minutes doesn't match "Consent is needed only once, ever, per a specific integration and a user".
I see that docusign uses cookies' values/expiration and can probably reverse engineer a GET call to account-d.docusign to get the bearer from the console app context, but that's not what I'd expect from an API provider.
For reference I'm using the following URL to manually get the bearer from the browser:
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature&client_id=d69848a8-2a93-4d03-ab40-bcabda8a7e8f&redirect_uri=https://www.docusign.com
But as stated above, it does expire in a few mins to get the aforementioned error_description
Thank you in advance!
Response type = code is the Authorization Code grant flow.
But for a console app where the implementation of the application is downloaded to the user's machine, the Implicit grant flow must be used.
This is because the Authorization Code grant flow includes a second API call, from the app to the OAuth Service Provider. This second call is used to exchange the authorization code for an access token. This second call requires a secret value, but there is no guaranteed method for keeping a secret in an app that's downloaded to the user's machine.
The Implicit grant flow immediately returns the access token to your app for use in calling the API.
Using the Implicit grant with a console app
Here are the steps. I also discuss this use case in my Electron React apps post.
The key is to use Private-Use URI Scheme Redirection to handle the authentication and receive the resulting access token. See RFC 8252 ยง7.1
Your app registers a http private scheme such as com.example.name_of_my_app with the operating system (windows). This way, any URL like com.example.name_of_my_app://app will be directed to your application to be processed.
Configure your DocuSign client id (integration key) to enable implicit grant and to use com.example.name_of_my_app://app as a return URL. No secret is needed.
When a user wants to authenticate with DocuSign via your app:
Your app initiates the implicit grant flow with the DocuSign OAuth Service Provider by "opening" the URL
https://account-d.docusign.com/oauth/auth?response_type=token&
scope=signature&client_id=xxxx-xxxx&
redirect_uri=com.example.name_of_my_app://app
Windows should open the default browser to the URL. The result will be the authentication page from DocuSign. Your app should NOT open a web view or similar. The operating system's browser should be automatically activated.
After the authentication is done, consent will be requested if needed.
Next, DocuSign will respond to the browser with a redirect to the redirect_uri. This will trigger your application and give your application the access token needed for API calls to DocuSign.
For some operating systems, your app can close the browser window that was created as a result of its URL open.
See the blog post for more info.
Added
As Ben says, your specific problem is that the authorization code that you receive back in the first step of the Authorization Code grant flow only lasts a minute or so. During that time, you exchange it for an access token (which lasts for 8 hours). But as I say above, you should not be using the authorization code grant flow, you should be using the implicit grant flow.
The token in the response only lasts about 2 minutes. Its true that consent is only needed once, but your problem is not consent.
I would like to upload a given file to Sharepoint. I'm using the Microsoft Graph API.
The documentation follows this workflow:
1. If no token, redirect the user to the Microsoft signin page.
2. The user is then redirected to the application, with an access token
3. Use access token to have an authorization bearer
4. Do what you gotta do...
My problem is the sign-in part. I don't want my users to be redirected to the Microsoft signin page. I want my application to connect and get the access token in the background (with cURL or whatever).
How can I do that? Why is the "open in browser" necessary?
I tried to replicate the sign-in process, but all I get back is the HTML response from the signin page.
Thanks in advance.
Your application act as a single-tenant service or daemon app.
The documentation about this scenario is here : https://developer.microsoft.com/en-us/graph/docs/authorization/app_only
The application must be registered in the AzureAD directory corresponding to the Office365 tenant
A first request is made by passing the application unique identifier and secret key as registered in the directory. This request returns an access token
The access token can now be used in the Authorization header of the following request to the Microsoft Graph API.
This method (of using Client ID and Secret) works well but there are other ways which may be better suited for similar scenarios.
The one major thing which is missing in access token generated this way is a user, meaning the token only contains the identity of the OAuth application (client) which called it but is not associated with any user for the request.
This could have a couple of implications:
Since the token is not associated with a specific user you will not know who performed the operation. In your example, you would not know who uploaded the file (and other similar information may be missing).
Access token without users will not work at all for some methods. For those, you need a delegated token.
Creating a delegated token requires some effort, if you are interested you can find the details in my article:
Getting Access Token for Microsoft Graph Using OAuth REST API
I'm building an ASP.NET Web API service which connects to Azure Graph API to get a list of users.
So my scenario is to create an MVC page on this service => let Azure AD admin login and grant permission => cache access_token and use this to call API.
However, I acknowledged that access_token will be expired after 1 hour. Even if it's renewed by using refresh_token, admin will actually have to manually sign in on this service again after 90 days.
I read on some example which use AcquireTokenSilentAsync method from ADAL library. But not sure if it would be useless after 90 days ?
Yes, currently the Access Token will expire within the hour. The Refresh Token will be valid for 14 days, and can be used to obtain a new Access Token and a new Refresh Token. You can carry on doing this for up to 90 days. (Note that these are the current values, they may change in the future.) AcquireTokenSilent and AcquireTokenSilentAsync will attempt to use existing state (i.e. Refresh Tokens, if available) to obtain a new Access Token, or throw an exception if this is not possible.
That said, I suspect that is probably not the best approach for your scenario. It sounds like you are in one of two situations:
You are building a middleware service (an API) that will be used by a different app which is accessed by authenticated users. If this is the case, you can use on-behalf-of flow, where (a) your middleware service is registered as a web app/API in Azure AD, (b) the user-facing client app and obtains an Access Token (for the current user) to the middleware API, and (c) the middleware API uses that Access Token to obtain a new Access Token to the Azure AD Graph API, on behalf of the original user.
Sample: active-directory-dotnet-webapi-onbehalfof
You just need to enable unattended access to the Graph API. If the middleware service is a highly-trusted environment, you can use app-only authentication (also known as "headless", or "daemon" apps) to obtain an Access Token without any user context. (This is the Client Credentials Grant OAuth 2.0 flow.)
Sample: active-directory-dotnet-daemon-certificate-credential
Sample: active-directory-dotnet-daemon
Yes, by default refresh tokens expire in 14 days (access tokens in an hour) but with some configuration I believe it can go until 90 days. This is for security reasons and a good practice. Nothing wrong with it. However, this will only work if you implement your own cache because by default ADAL cache uses memory and upon restart it will lose those tokens.
https://github.com/Azure-Samples/active-directory-dotnet-webapp-webapi-openidconnect
I am posting this here, as Docusign has requested all docusign api questions be placed on StackOverflow:
REFERENCE
I have been working on a Docusign application that uses their OAuth flow. In order to test this, I have been using my free account (www.docusign.com) to get access tokens from the application I created on my developer account (demo.docusign.net).
The integrator key I am using is live.
In the process of my testing, I have obtained an access token 10 times using the free account. I did not keep track of those tokens as it states that they can be revoked in the web console. Docusign Reference
However, there is no such section in the www.docusign.com account. All it shows is 5 other accounts that I can connect to.
I now have lost all 10 of those tokens, and the response from the service tells me that I reached the maximum number of access tokens.
Now here's the interesting part, if I use my developer account credentials to authenticate to my application, I can see the access tokens that are active, with the option to revoke.
I know that there is a revoke token endpoint, but you need to know the token in order to use it.
How can I revoke these 10 tokens as I no longer know what they are (due to testing), and there is no interface to revoke them on www.docusign.com? Essentially, this account is now locked out of my application.
I cannot add screenshots to this post as I do not have high enough reputation
In my case, company B (domain B) hosts a portal, which has link to my web app (domain A). If user clicks on hyperlink on the portal to my domain, he/she should be automatically logged into my app.
Existing poilicies that i cannot change:
User also has the ability to log into my domain directly, without going through the portal by supplying user id/password.
Also, existing company policy for user provisioning is that even if user log through portal of company B, they first need to have a user account with my company. Hence, the user will have account with portal company and my company.
Given these constraints, my plan for is following to provide automatic login from the portal.
When the user logs in to the portal, the portal company will generate a temporary token (UUID) and attach it as a query parameter to the hyperlink to my web app. When user clicks on my web app's hyperlink, my web app will receive a GET/POST request on the server side for a protected resource. At the server side, my web app will over https (probably two way SSL) invoke a URL on the portal's side, passing the temporary token. The portal side responds with a user id. My web app will map the user id with user's credentials and create a session for the user and allow access to the protected resource.
When the user logs out of the portal application, the portal server will make an Https request to my web app at a prespecified URL to log the user out. Since it would be two way SSL, logout url is protected.
My questions are following:
Is there a standards based approach to achieving the above scenario. In near future, my company is planning to support OAuth 2.0 and i want to ensure that the above scenario will not violate any OAuth standard. As per my understanding, OAuth 2.0 leaves the validation of the access-token to the implementations. I am hoping that the temporary token described above is sort of access-token.
Once the user closes the portal browser, is it possible for browser to destroy the cookie. In this case, if user opens another browser later on, he/she should authenticate again.
Is there a standards based approach to achieving the above scenario. In near future, my company is planning to support OAuth 2.0 and i want to ensure that the above scenario will not violate any OAuth standard.
You kind of like answered your question already. That "standard-based approach" is OAuth which a Standards Track already documented by IETF in RFC 6749 and has been adopted by many software entities. If you don't implement OAuth then you are not violating the standardisation rules, you will be violating it if you claim to have implemented OAuth authorization in your system which clearly you haven't.
As per my understanding, OAuth 2.0 leaves the validation of the access-token to the implementations.
Well, OAuth is a bit more complex than just generating an access token, there's an authorization grant request involved before you can request an access token. You could also expose a token refresh endpoint if the life span of the access token needs to be extended by the client. So, there's more than just access token requests involved in OAuth authorization process
I am hoping that the temporary token described above is sort of access-token
What's an access token? It is up to you how you implement an access token, the implementation details belong to you and nobody else. The only thing that you need to guarantee is that the access token represents the authorization issued to client and its scope, in other words, given an access token your system should be able to identify a client and the scope of this client...what the client is allowed to do, what resources the client is allowed to request. Be aware that OAuth defines clients which doesn't directly translate to users, it could well be a user, another system, component or app.
Once the user closes the portal browser, is it possible for browser to destroy the cookie. In this case, if user opens another browser later on, he/she should authenticate again
Absolutely, yes. This is not related to OAuth at all, it's up to the client what they do with the access token and how they store it. If your system issues a non-persistent cookie, then as soon as the user closes the browser then the browser session is destroyed and also the cookie. All modern web development technologies offer cookie management implementations such as JSP, ASP.NET, PHP, etc. So I would suggest to store the access token in a non-persistent cookie and have your authorization server inspect requests to all protected resources by checking for the authentication ticket/cookie (where the access token is) and validate the access token, if the access token (or cookie) is not present then reject the request since it is an anonymous request to a protected resource.
Hope it makes sense