I'm trying to implement persistent access token usage on the client side and would love to hear about the right way to go about it.
Right now I have a wpf application working with an identityserver3 backend using code flow. I use a long lived refresh token.
My idea for keeping the access token alive is to check the expiration of the access token upon every request and under a specific value to do a refresh token.
Is this the optimal way to go about it?
Also what would be the optimal scenario for refresh token refreshing? Should I also monitor the expiration?
Thanks
Found this answer on the project git https://github.com/IdentityServer/IdentityServer3/issues/358
Related
I am using Authorisation Code Flow in my web application. I would like to get a refresh token for the web app itself but also an offline token that I will save in the database so I can use it later on for an offline task.
However I am struggling with that. I cannot use grant-type password because I don’t want to ask the user again to enter his/her credentials and also authorisation code is only one-time use so I cannot integrate it with the current flow.
Is there any other way to generate an offline token from a different token? I have tried using grant type refresh-token with scope offline_access but that didn’t work.
After keep working with Keycloak for several months, the answer is simple: it is not possible.
Offline token is effectively a refresh token with no expiration time so you can get one or the other but never both as part of the same request/response.
From a user point of view, we created a new page to request this token using password grant-type and offline scope. User need to re-enter his password but it seems ok from a security point of view. This approach works for us given the requirements to get this token as it is an unusual task.
You can also generate offline tokens using service account, check keycloak documentation on service account.
Following discussion will help you to understand different scenarios generating and using offline tokens
I've been reading abount using Passport for the authentication process in a MEAN stack web app. I've been following this tutorial, but I got confused when it comes to the refresh tokens.
I do understand that those tokens are used to get a new access token for the user once it has expired, as explained here and in any other OAuth tutorial about thos tokens, but what I don't understand is how the server knows which refresh token must be used if the user hasn't provide any credential (it is supposed to provide the credentials just the first time is logging in).
Can anyone help me with this to fully understand how this works?
Thanks a lot :)
The Authorization Server issues the first refresh token after the user has authenticated. It then stores the association between refresh token and user as part of server side state so that it knows which refresh token was issued, whether it is still valid and for which user.
When the Client comes back to the Authorization Server with the refresh token later, the server can lookup the context and associated user from the server side storage.
Well, finally it turned out that the tutorial I was following was wrong (at least on what it comes to the refresh tokens).
On the tutorial it said that Passport use the refresh tokens to send a request to the Auth Server to get a new access tokens. Well, that's not true. According to Jared Hanson, the author of Passport, Passport doesn't handle refresh tokens, that's something the backend of the applications have to handle if desired. Passport is just meant to make the first request to the Auth Server, when you get the access and refresh tokens. Then you can use refresh tokens to request new access tokens, for example using background tasks to check if any access token is going to expire anytime soon.
I think the one who wrote that tutorial was confused cause the second time you login with whatever strategy is available (Facebook, for example), the service doesn't ask for credentials, but that's not because of the refresh tokens, that's just cause the browser is saving the FB session. If you go to FB and logout, the next time you try to login in the app with FB, it will ask again for the credentials. In fact, if I'm not wrong, access and refresh tokens should be removed once a user logs out. Kind of surprising that you could find that kind of mistakes in a IBM developers blog.
BTW, Jared Hanson's comment about how Passport works (without using refresh tokens) can be found here. Since is an old issue, I asked him myself on Twitter and the answer was just the same :)
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.
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.
I need to download my Delicious bookmarks to a non-web application without constant user interaction. I'm using Delicious's V2 API (using oAuth) but the problem is it seems their access tokens expire after one hour.
I don't have any issues with redirecting the user to Yahoo for a one time authorization, but what is described here (http://developer.yahoo.com/oauth/guide/oauth-refreshaccesstoken.html) means I would have to refresh my access tokens all the time before they expire when the user is away.
Is this really the way they've done their oAuth implementation?
You only need to refresh the access token when they come to use the application again, not while they're away. You can pass the previously expired token and get a new one in return.
Is that a problem? You should only need to make an additional server-side call to refresh the access token if it expires (as long as the authorization itself has not expired, which should last longer, and would need user interaction when it expired).