I'm developing a .NET application that can send emails on behalf of the user using the Graph API.
Users are prompted to authorize the application; The acquired access token is then used to call the Graph API. The refresh token is used to issue a new access token when the old one expires, as described here: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow
Couple of questions / observations:
Assume user John authorizes the app to send emails on his behalf. If an administrator removes the app from the azure portal, the access/refresh tokens issued when John authorized the app will still work.
if the access token is still active, it can be used to call the graph api;
if the access token is expired, the refresh token can still be used to request a new access token
Is this behavior intended?
After reading https://learn.microsoft.com/en-us/azure/active-directory/users-groups-roles/users-revoke-access and https://learn.microsoft.com/en-us/powershell/module/azuread/revoke-azureaduserallrefreshtoken?view=azureadps-2.0 it seems that simply removing the app from the user doesn't revoke the tokens.
Assume user John authorizes the app to send emails on his behalf. If John goes to https://myapplications.microsoft.com and removes the app he won't be able to use the refresh token to get a new access token, which is expected.
However, I've noticed that if John reauthorizes the application to perform actions on his behalf, the application won't show up on https://myapplications.microsoft.com anymore. This behavior seems a bit inconsistent. What's the proper way for a user to revoke access to an application?
If the user has granted access to the application, Azure AD will issue an access token and a refresh token for the resource.
The lifetime of the access token is usually about 1 hour. During its lifetime, even if the application is deleted, it is still available, but you will not be able to use the refresh token to obtain the access token again.
If you need to revoke authorization during the lifetime of the access token, please see: here and here.
Related
I'm using the Dropbox SDK for DotNet, and it is time to support short-lived Access tokens.
My use case is uncommon (web site, 'backend side'). Once the link to DropBox is made, everything should keep working unattended.
In fact, it is OK to never publish the app. Each user creates its own app in their own Dropbox account and stays on Development mode forever.
Until now, the user created the dropbox app, takes note of the App key, App secret and generates an access token directly at https://www.dropbox.com/developers/apps/info/....
With this data, the application was working fine, but Access tokens will soon be short-lived only. I already verified the like to dropbox gets broken after the generated (from www.dropbox.com/developers/apps) Access Token expires.
How can I, using the SDK and having a valid Access token, get a refresh token to be saved and utilized to get a renewed access token?
I couldn't find any way in DropboxClient.cs, DropboxOauth2Helper.cs, not the examples at https://github.com/dropbox/dropbox-sdk-dotnet/tree/main/dropbox-sdk-dotnet/Examples
It is not possible to use an access token to retrieve a refresh token. A refresh token can only be retrieved via the OAuth flow. I recommend reading the OAuth Guide for more information.
The "Generate" button on the app info page on the App Console does not currently offer the ability to generate a refresh token, but I'll pass this along as a feature request. I can't promise if or when that might be implemented though.
A requirement is set upon me to implement impersonation for developers, of course only for development environment. I was wondering if it is possible to request a token for any AAD user without knowing the password. The flow I would want is:
Developer goes to web application to select a user he wants to impersonate.
The web application checks if the developer is in the AAD.
The web application checks if the developer has the necessary rights to impersonate.
The web application returns a token valid for the user the developer selected.
The developer can use this token to authenticate against the API, and for all intents and purposes is the impersonated user.
Any good alternatives to this approach are also welcome.
No, you cannot impersonate a user like this.
You can acquire an access token if you know their password and they don't have MFA etc. with the Resource Owner Password Credentials grant flow.
But if you want to do it in a better way, you could have the users who you wish to impersonate login to your app.
Acquire an access token + refresh token for them.
Then store the refresh token securely.
Now you can use the refresh token at any time along with your app's client credentials to acquire a token for that user.
Refresh tokens can and do expire though, for example if the user's password is changed.
But this could allow you to implement what you want.
I am trying to authenticate my application using azure AD. But at one time I am able to login at one place. When I am trying to login in other place it is not authenticating. I read somewhere that IsMultipleResourceRefreshToken should be true in AuthenticationResult. Can anyone help me how to get IsMultipleResourceRefreshToken to true in Azure AD authentication?
The IsMultipleResourceRefreshToken flag describes the nature of the refresh token you received. You cannot change it. However, there should be no scenarios TODAY in which the refresh token returned by Azure AD is not multi resource. I recommend you ensure you are using the absolute latest version of ADAL and that you are actually using a flow that returns a refresh token.
Furthermore: it is unclear if "login to another place" refers to obtaining a token for another resource, or for another tenant. If the latter, please note that tokens are always bound to their tenant and do not enable the issuance of new tokens for a different tenant.
Note: This is not about coding, but about the approach itself.
I'm making a client for a website which uses OAuth 2.. Since this is my first time using oauth 2 I have some problems in understanding the approach. As I know until now:
I should send my access token with every request. To get this access token in the first time I send user to the website and after login I get an authorization code. Then I send this authorization code and my client_id and client_secret to get the access token and finish.
until here every thing is fine. But in the next application execution, I don't know what to do. I don't want to ask user to login every time. But how can I know my access token is still valid?
should I save my authorization code and request a new access token again?
I request a non-expiring access token, but to refresh the access token I should send some refresh_token? What is this? Should I send the old access token as this?
#Eugenio's answer is correct.
To answer your specific questions
But how can I know my access token is still valid?
The access token comes with an expiration time, usually one hour. The other way is to try to use it and catch the 401 status if it's expired.
should I save my authorization code and request a new access token again?
No. The authorization code can only be used once. You can either request a refresh token, save that, and then use that to get subsequent access tokens, or you can repeat the authorization process, which depending on the provider, may or may not require user involvement since the provider will know that the user has previously authorized your app.
I request a non-expiring access token, but to refresh the access token I should send some refresh_token?
There is no such thing as a non-expiring access token. You use a refresh token in order to obtain a new access token.
What is this [refresh token]?
It's a string that your app can pass to the provider to say "hey it's me again. Remember a while ago user xxxxx, granted me, application yyyy (client id), the authority to do aaaa and bbbb (scopes) on his behalf, even when he's not present. Well I'd like to do some now so please can I have an access token".
Should I send the old access token as this?
No. Once an access token has expired it has no use or significance at all.
The access_token you get from the authentication site is good to call their APIs, not your app. You should keep it if you need to call them back eventually in your app.
For example, if your users are authenticating with Facebook, the access_token you get will be good to call Facebook's endpoints.
OAuth2 is in essence an authorization protocol: the user is granting you permission to access his/her information on their behalf.
A commonly used, and useful side effect of this process is to treat these users as "authenticated" because, presumably, you can only get an access_token from a legitimate user.
It is then up to your site to establish a session with them. You would do this exactly as you would if you were authenticating the user yourself, likely after you successfully retrieved the access_token using the code. (or sometimes after retrieving the user profile from the Authorization Server, another common technique).
You can browse a sample that does this on the .NET platform here: https://docs.auth0.com/aspnet-tutorial (this is configured to work with our own OAuth server, but the principles are generic).
The code this sample relies on is available here: https://github.com/auth0/auth0-aspnet
I want my web server code (invoked from ASP.NET MVC3 site's controller) to be able to save files to Dropbox account.
I have examined two out of three .Net/Dropbox libraries and all of them require a user to "authenticate" via web-redirect to Dropbox to get a token.
Examined libs are Spring.Social.Dropbox and DropNet.
Can this authentication and upload be done via purely .net code without messing with the user's browser? Can the acquired token be saved for later use? This is theoretical question, not about particular implementation.
This is a bit of a complicated subject. As far as I know Dropbox uses OAuth, which is an authentication and authorization protocol.
General process is this:
You create authorization request token
User gets redirected, authenticates and grants permissions to your app.
You trade the request token for an access token
You must save the access token because it is used to perform actions on the users behalf
Access tokens don't usually expire and only stop working if a user revokes your application permissions.
This means the user will have to authenticate and authorize your application at least once so you can get the access token and access token secret.
After that, you are pretty much free to perform actions on the users' behalf based on the permissions granted. You must specify the access token attained by the above-mentioned process in order to perform actions.
In short, get an access token, save it, use it for requests.
Does this clarify it a bit for you?