In my app after initially logging in using username and password, the server returns a time-based token. This token needs to be sent to the server on each request.
When the token expires, a call must be made to the server to return a new token. This requires the user to pass his username and password.
My question is how should I be storing these credentials for when I need to get a new token? Or should I be trying to get a new token just before the old one expires?
Thanks for your help.
You should keep the token "live" for X minutes (depends on you) after the last time the user was active, means that with each request to the server the timer of the token should be reset .
once the token has expired, the user should get notice and maybe re-enter his credentials, depeneds on how secure you want your system to be, are you allowing 'remember me' option, etc ..
If you are allowing 'remember me' option, then the user should just click 'log in' and the credentials can be saved in the cookies, encrypted ( for very secure system you may use public - private key pattern ). If you are not letting the user to choose such option then he should re-enter his credentials once the token is expired .
Of course this is a suggestion and some other implementation can be done, but i think this is what are trying to do .
Related
Recently I am learning oauth 2.0, and all the docs said that when the refresh token invalid or expired and let the user to relogin. To my experience to use the apps, no apps need to relogin again after the first login. how did they do that? store the username and password and refresh the refresh token with the username and password? set the refresh token for a long time(for example, set the refresh token 5 year to expired)?how did they do that?
this is what we could silent refresh, when the client connects the first time, the token is refreshed in the background with the refresh token before the token expire, and for your refresh token, you don't need long lifetime you need just to keep the latest one.
see my other answer here
I know an access token is self-contained and therefore can't be revoked.
To my understanding, this is why the expiration time of an access token often is low. This enables one to revoke the refresh token, and thereby only allow users to be signed in, for the expiration time of the access token.
However, if I understand it correctly, a user is able to renew his token infinitely without the use of the refresh token.
One can initiate a silent authentication request by adding prompt=none. This is possible as long as your access token is still valid. Doing so will return a new access token, that is indistinguishable from a login performed directly without the prompt=none parameter.
If I understand this correctly, a user who once got a valid token is able to constantly renew this without me being able to "revoke" his access in any way?
Am I understanding this correctly, and if so, how do I go about revoking a user's access until he manually signs in again?
The prompt=none silent renewal actually uses the user's IDP authentication cookie and not their access token.
The good news is that ASP.Net Core allows you to store the data held in said cookie on the serverside (e.g. in a database or distributed cache) and thus you can revoke said cookie any time you like. By deleting the cookie data related to that user account you effectively invalidate their current session(s) and thus can prevent any future silent renewals. Likewise you can delete all persisted grants (reference tokens and refresh tokens).
Check out the Microsoft.AspNetCore.Authentication.Cookies.ITicketStore interface and the CookieAuthenticationOptions.SessionStore property.
Is it possible to authenticate a user using Google OAuth without forcing the user to choose allow / deny (ie. is it possible to "auto-authenticate") when I already have the user's refresh token, but their session with the application is no longer active?
Such as:
The user is using a different computer
The user is using a different browser on the same computer
The user's computer is re-imaged on every restart / cookies cleared on restart
Our session cookie expired
Note that I've set approval_prompt=force since I need the refresh token. Thanks.
Depends what you want to do... no user interaction is required to use a refresh token to get a new refresh token for whatever the scopes were. But a refresh token can’t be used to verify user presence, its whole point is to do this stuff when the user is absent.
If what you need to do is test that the user is present, you have to go through some sort of authentication interaction, with one exception. If you know the email address and do an OpenID Connect login with a scope like "openid email" and you send the email that you know about along using the login_hint parameter, then if that email user is present and signed in, your operation will succeed with no interaction required. Some useful details are at https://developers.google.com/accounts/docs/OAuth2WebServer
I'm using the Doorkeeper gem to provide OAuth in a Rails app. The client is a Chrome extension.
I have 'use_refresh_token' commented out in doorkeeper.rb, and 'access_token_expires_in' set to 1 minute. I thought that would force the client to re-auth after a minute. But re-auth is happening automatically, regardless of whether use_refresh_token is present or not.
With use_refresh_token present, a new row is added to 'oauth_access_tokens' every time the access token expires. No new row is added to 'oauth_access_grants.'
With use_refresh_token commented out new rows are added to both tables. Which I would expect if the client was manually re-authing. But it appears to be happening automatically--the user is granted access without having to re-auth the app through the OAuth login screen, as I'd like.
Apologies for my ignorance, I'm new to both Doorkeeper and OAuth and haven't found any clues on Google et al.
The OAuth 2.0 is working as it is sending authorization URI to authorize url to get the access token and while the user is not authorized to get token the server redirect him to login page, I think the point in your case that the expire in time is too short so the session opened when user entered username and password for first time still valid so when your client asking for new token it is getting it as the user is still loged in on the authorization server, you can change the time of session to be less than the token validity time and test it.
I am implementing a login process for my app, for that I have created a login screen and a sign-in button. So if the user is not signed in I have a register button which opens another form so that the user can register himself, after which I have provided a Done button which when clicked will send the information to the server and sends an authentication code to the users email address that the user entered in the iPhone app. Then the user will be registered.
So now I want to know what are the best ways to send the username and password to the server once the user is logged in? How is it possible to save the user name and password so that when at later time when the user opens an application he should not be allowed to login again?
The easiest way for secure transmission of the credentials is to use Https. On successful authentication you'll receive a "cookie" that you can store locally in the user defaults. That cookie will typically expire. So, on subsequent logins, you can check that the cookie hasn't expired, and continue to use it for your server communication.
If the cookie does expire, then you prompt the user to login again, thereby receiving a new cookie from the server.
Storing any user credentials on the device is a big no no. The only way you can do it is to store a hash of the password. You would still need to check a hash of the entered password with the stored hash to check they are equal. It doesn't really give you anything other than a local - no server required - authentication.
Of course don't forget that without having to login again, the app will be vulnerable. Someone else could use the app and the owner's server session would still be active.