Should the Oauth tokens be revoked if the customer goes through a forgot password flow and changes his password
One reason for changing a password is when a user notices that someone else had access to his account. In this case an attacker who had once access with the old password and used OAuth to get an access token could still have access to the account, though the user changed his password to prevent this.
E.g. for some obscure reason (weak password, trojan, etc.) your GMail account was hacked and used to send spam. The attacker used Google's IMAP with OAuth feature and got a valid access token. Now somehow you notice they're sending spam in your name and you change your password. The attacker still has a valid access token and can continue sending spam.
Revoking the token should be independent of the reason, why the user changes his password. If he changes it, you should revoke all tokens and let him sign up once again.
Related
For refresh token rotation and update both refresh token and access token way, I am wondering, for the same user, if he or she opens different browser and logs in. This means, for the same user, tokens rotation would think it is stolen. Am I right?
If I don't want this to happen, can I use IP combined with user ID to identity the user? Is it secure? I know if it is shared IP, then no.
Is there anything that hacker cannot fake which can distinguish hacker and the user? I think Phone has its device ID of some sort. How about browser?
I think you are confusing completely different concepts
Oauth - authorization.
Open id connect - sign-in - authentication.
Access tokens and refresh tokens are used for authorization. A user grants your application access to their data. The user does not have to be present for this to happen. There for using an access token to prove a users identity is not the correct course of action.
You should use open id connect, to authencation a user - sign them in. Then you should get an id token back which contains claims, one of these claims is the subject claim which should be the users id on the system you are connecting to. You should use that to identify the user.
As for hacking oauth. (Authorization)
Access tokens are short lived they will give your application access to a system for a limited amount of time usually an hour. If a hacker got the access token they would also have access to the system for this hour. access tokens are self contained. no further verification is preformed.
Refresh tokens require the client id and client secrete in order to request a new access token. So the hacker would need to have your client id, client secret, be on one of the valid redirect uris. in order to request a new access token. This is why you should not set a redirect uri to localhost.
Hacking and open id connect.(authencation)
Well as far as signin goes the hacker would need to have the users login and password in order to signin in and get an id token back. You should be good to assume that this is not a hacker and is the user behind the machine.
I'm following this article to understand refesh tokens.
In my case I have to connect to REST api using grant_type=password, and I receive a token with a 5 minute lifespan. So every 5 minutes I have to issue a POST request passing client-id, username & password to get a new acces token.
The other option would be to issue a POST with a grant_type=refresh_token, without having to send the username & password. In my case I'm consuming an api, so passing the credentials doesn't involve any action from the final user. For me it's just to params more to send on the POST request.
In both cases, I have to issue a new post every 5 minutes.
Is that the only advantage (not needing to pass credentials again) of using the reresh token or is there any other thing I'm missing?
Background info
OAuth 2.0 Password Grant
The Password grant type is a way to exchange a user's credentials for an access token. Because the client application has to collect the user's password and send it to the authorization server, it is not recommended that this grant be used at all anymore.
OAuth 2.0 Refresh Token
The Refresh Token grant type is used by clients to exchange a refresh token for an access token when the access token has expired.
This allows clients to continue to have a valid access token without further interaction with the user.
Consider this.
Lets say that i add my login and password for my twitter account to your application and you then use that to request access from twitter to may account to post. Three months later i have forgotten i have set your awesome app up to do something on my twitter account and i change my password. Your system will break.
Now lets say i used Oauth2 to grant you access to my Google drive account, your awesome app can now do what ever it needs to do on my drive account. Now three months latter i have again forgotten i gave your awesome app access, I have the memory of a gold fish you see. I change my password. Nothing happens your awesome app still has access.
Now consider this, With oauth2 i can grant you access to only read from my google drive account not update it (scope). That and the system knows its not actually me preforming the actions.
With client login (login and password) most of the time it appears to the system that it is the actually owner of the account making the requests. You can also not limit access with client login for the most part you have full access.
note
yes i am ignoring the part about both tokens returned being the expiration time time. Thats because for all intensive purposes they are the same but that depends greatly on how the auth server you are using is set up. They could be set up to only be valid for an hour or a day. They may give you different access scopes, again this differs greatly from auth server to auth server.
I'm working on a SPA app based on Node, with token-based authentication using JWT. Right now, the jwt token never expires, which is not good.
I want it to expire for more security, but I don't want my users to be forced to re-log. That's why I need a refresh token.
So i'm reading about OAuth2.
I have a hard-time to understand why refresh-tokens must be stored in a database, whereas access-token are generated on the fly using a secret key.
Why refresh tokens can't be generated the same way as access tokens ?
Thank you guys !
Refresh tokens usually are generated the same way as access tokens.
An authorization server will often return a refresh and access token if requested (and you're not using the implicit grant type).
The difference is how they are used.
An access-token is usually a bearer token: whoever has it can use it against the resource server, but it is only valid for a short period of time. In which case, storing them in a database is often pointless as they are worthless once expired.
A refresh token however is like having access to a "forge" which allows you to mint a new token.
If you present the refresh token to the authorisation server (not the resource server) you will get back a new access token and possibly a new refresh token.
Providing of course that the user has not revoked/changed access permissions to your application and that the user is still a valid user.
So you would keep them in a database perhaps because your user logs in infrequently. So you may need the refresh token weeks after you got it.
Alternative to the refresh token.
If you are using the implicit grant (which is common with SPAs but not recommended). You can try and keep your end user logged in to the identity provider used by the authorisation server. This way you can keep requesting new access tokens from the auth server without the user being prompted by the auth server for credentials as a session will be persisted between the identity provider and the user's browser.
I'm testing the use of OAuth2 for MS Office 365 in order to read calendar events, and just read the following in this blog post:
...the refresh token, while long living,
becomes invalid at some point too. One example is if the user changes
their password, refresh tokens become invalid.
From my experience with other OAuth2 providers, the refresh token should not expire when users change their passwords (isn't that one of the main purposes of the token - to allow password independent access?).
Am I missing something? What is the reason behind expiring the refresh tokens when password changes?
A password change may happen after a password breach. Access & refresh tokens may have been issued during the time between the password breach and the detection, these tokens would need to be revoked as well as the password reset. To simplify administration of that - the exact time of the breach may be very hard to detect - all access is revoked and needs to be explicitly re-assigned by the Resource Owner.
Normally users do not change their passwords without a reason. One of the reasons is that user might think his password might have been leaked. In such case it is not clear which of the refresh tokens (logins) are authentic and which are from a possible hacker.
I'm developing a Twitter application on OAuth and I want to provide the ability to post updates in the future.
The basic plan is to run a script every hour and find any updates which need to be posted, and then authenticate the appropriate user and use the statuses/update API call.
However, I don't know how I can use OAuth for this. I obviously don't want to store their username and password - that defeats the object of using OAuth in the first instance.
If, though, that is the only option, then how can I not store a plaintext copy of their password but still authenticate them?
With OAuth you only need user credentials initially to get the oauth token. After you have the oauth token, you use the oauth token in place of those credentials. The only issue in subsequent calls under OAuth is any TTL (time-to-live) associated with the token on the service-side. Twitter does not apparently expire tokens, so once you have a valid token you should be able to continue to make calls on behalf of the user. The only times you would need to get credentials from the user are (1) in the initial stages of running the application, or (2) if the user's session becomes invalid for some reason (changed password, user-directed invalidation of the session, etc.).
See the OAuth spec for more details.
Note that should you intend to use the same user token between invocations of your application, you should be prepared to encrypt the token and store it securely. Should someone capture your consumer key and secret, along with the user token, the identity of the user can be compromised.