Why not use just one for everything? Refresh token doesn't change by default, so why bother to get an access token every hour? API: https://developers.google.com/youtube/2.0/developers_guide_protocol_oauth2#OAuth2_Server_Side_Web_Applications_Flow
They choose that the given access does not last forever: So you need to get a new access token once it has expired.
The purpose of the refresh token is that you have to ask the user for permission only one time.
Here's a good discussion on the topic.
When you get a refresh token, you also need the client ID and secret. With an access token, you can make API calls using just that. A lot of this comes form learnings from OAuth 1.x, which had a much more complex signing protocol - it just caused lots of bugs and problems with client/server protocol mismatch. Using only an access token made API calls, the most important part of OAuth, much easier to implement and maintain.
Related
I m using a client credential flow to access the API. I am getting the access token each time client make a call to Web API which seem to me may not be good but not sure why. I looked through web I am getting mix answer, some say Client Credential flow doesn't return refresh token some say possible but it is not clear how. I looked at the project where it seem to store the token in the cache but doesn't show how it can be use when needing to get the access token.
Even if Client Credential flow doesn't support or send refresh token. I am searching for a way to store the access token and use it until is is not expired and get a new one when it is expire. This is where I am looking for support.
Beside that I do have relevant question.
Should I just get the access token each time? what is the downfall of it?
Should I include a Test method is Web Api to validate if the token is expired and return "Unauthorize" response based on that response I get the new token? With this approach, I will calling the API each time I need to access the API for actual purpose. So wouldn't I just get the access token from the Authorization server (Microsoft Identity platform).
Have a look at these resources:
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Client-credential-flows
https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-net-token-cache-serialization?tabs=aspnet
One possible solution is to implement internally your own solution:
Get the Token.
A Dictionary is going to hold the (API type) as a key and the corresponding token as its value.
Next call check if the token exists in your Dic(TryGetValu(ket, out param)).
Check "ExpiresOn" on the AuthenticationResult (the Token) and compare its time for validation.
Remember to maintain your Dic by Updating or adding new tokens.
Is it possible to "reduce" scopes in OAuth? Scope reduction should be initiated by the client.
Meaning: Request a new Access Token using the Refresh Token, but the new token has less scopes than the "original" one?
Use case: I'm developing a client application that authenticates users via OAuth with another party (A). Now I want to give yet another party (B) access to some scopes, but less than I have.
Unfortunately there's no standard way to do what you want, but even if there were, you can't often get a new access token without destroying the old access token.
Access tokens are per-client. Once it expires, you can use a refresh token to get a new access token, but many systems are implemented in a way that a refresh token can only be used once and that the original access token immediately (or quickly) expires.
If you control the server, it's definitely possible to implement this as a new, custom grant type, effectively an extension of OAuth2.
According to https://www.rfc-editor.org/rfc/rfc6749#section-6 you should be able to add a scope field on a refresh request, as long as your requested scopes are a subset of the originals and your refresh token is still valid.
Note that the reduced scopes only apply to the access token, so if you leak a long lived refresh token to a third party they can get all the scopes it had.
How I can enable multi resource support in iOS using ADAL.Searched in so many sites, but finding it difficult to understand the flow with multiple resources, with Refresh Token and Access Token.Can anyone explain this flow briefly please?
According to library, ADTokenCacheStoreItem will have accessToken will be nil, in case the item stores multi-resource refresh token.But whenever I will call acquireTokenWithResource:clientId:redirectUri: I am getting both access token and refresh token.How I can tell the library that mine is multi source request.Is there any settings I need to do?
/*! The access token received. Should be nil, in case the item stores multi-resource refresh token. /
#property NSString accessToken;
And also , do I need to call the acquireTokenWithResource:clientId:redirectUri every time before calling each API with or without different end points.Or is it my responsibility to cache/store the access token and expiry date for each resource?
Also how I can handle silent login in multi resource case?
With ADAL, you simply need to call some form of acquireToken* each time your application needs an access token, presumable to make an API call. ADAL should take care of token caching, refreshing, etc for you. You shouldn't ever have to manually use refresh tokens.
Refresh tokens from Azure AD are inherently "multi-resource". That is, you can ask for an access token to resource 1, receive that access token + refresh token pair, and then use the refresh token to get an access token to resource 2. This allows you to get tokens for different resources "silently", meaning the user only has to sign-in once.
My Access Token is expired after 1 hour and videos are not uploaded in to you-tube due to invalid access token and every time asking for authentication.
How to reactivate existing token or refresh access token.
You schould use long-lived token. There are several methods to get it, but everything is well described here:
Facebooke developers extending tokens
If you want more precisious answer please write in which language are you trying to do that.
I'm trying to add authentication feature to my application.
The authentication server implements oauth 2.0
I'm not sure how to save the refresh_token. I want to save it to a file, so next time when the application starts and there is a refresh_token available, it can ask for a new access_token. The user won't need to re-login again.
But this doesn't sound secure to me, because if someone copies my file that has the refresh_token to another computer, he can hack into my account.
You are correct with the attack that you describe. Refresh tokens have to be stored securely in order to be used as intended. As I understand, you are building a standalone application. Therefore, you can rely on file system security to prevent a refresh token being copied by an unauthorized user. You may want to use encryption for the refresh token, too, but the key would need to be bound to a user's session at your local machine (otherwise, the user would need to provide it during "sign in" process in order for the application to decrypt the refresh token).
Consider reading the thread from the OAuth WG, that discusses similar problems to the one described and provides some guidance:
https://www.ietf.org/mail-archive/web/oauth/current/msg02292.html
Refresh tokens are used to obtain access (this process requires HTTP Basic Auth). So, unless user has your (id,secret) combination he can't do much about it. However, storage of refresh token must be considered very seriously.
Here's my two cents:
Store your tokens in a DB
Whenever you use refresh token to obtain access token reset the refresh token as well. (Oauth2.0 has this feature, you can let the refresh token unchanged too, but it's wise in terms of security perspective to keep it changing and updating the DB)
Hope this gives some insights!!
You are right about your concern - you should not save the refresh token. By doing so, you jeopardize your client's data (and you know the reason; you wrote it in the question).
oAuth is not supposed to work this way.
You should keep the refresh token in-memory.