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
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.
Does ORY Hydra currently have a feature that verifies if a client is logged in via OpenID Connect? I notice there is an API to logout via front-channel
When a user revisits the identity provider, however, I have no way of knowing if they are currently logged in or not. They could delete their client-side HTTP cookies and then I am out of sync with Hydra. Meaning: Hydra has them as logged in, but I have them now as logged out. Also, in the event of a back-channel logout, I want to be able to query for this state.
Is there an API I am overlooking that allows me to know whether a client currently has an active OpenID Connect login via Hydra?
It appears as of right now the only thing one can do is redirect the user to the authorization endpoint since we have no way of knowing if they are authorized or not.
The following two tables that ship with Hydra seem to be the source of truth for the data I am after: hydra_oauth2_access and hydra_oauth2_authentication_session. Does it ever make sense to query those directly if there is no supported HTTP API out of the box to see if a user has an active authentication session?
Sending an authentication request via a redirect to the Provider including prompt=none addresses this use case: it will silently login and return new tokens if there's an ongoing SSO session at the Provider, it will return an error code login_required if not.
Notice there will never be explicit user interaction in both cases so this is convenient (and meant) to run in an hidden iframe.
LOGGED IN STATE
An OAuth client is most commonly a UI application with multiple users. Each user's logged in state is represented by an Authorization Server session cookie that neither the application or user have access to:
The Authorization Server (AS) issues an SSO cookie, to be stored in the system browser for the AS domain
Both Web UIs and Native UIs send it implicitly on subsequent requests, when they invoke the system browser
AUTHORIZATION REDIRECTS
When an OAuth UI redirects the user, it is generally unknown whether:
The user will be prompted to login
The user will be signed in silently (eg the user could have signed in to another app)
For a Web UI it is possible to send an authorization redirect on a hidden iframe with a prompt=none parameter. If the user needs to sign in a login_required error code will be returned. See my Silent Token Renewal Page for further details.
This is not fully reliable however, and has some browser issues in 2020. Also it may be unsuitable if you are using a different type of client.
FEDERATED LOGINS
In some setups the AS redirects further to an Identity Provider (IDP), and the user's login state is further influenced by an IDP session cookie.
There is no way for an app to get hold of the user's IDP login state, since the app only ever interacts with the AS.
IS THERE A USABILITY PROBLEM?
If so, post back and we can discuss further ...
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 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.
I have a Twitter web app that allows users to submit tweets from my site. However they have to re-login every time they submit a new tweet. Is there a way to save the OAuth session and don't prompt the login screen until users clear their browser cache?
When you get the callback from Twitter after the user has validated you, you'll receive an auth_token in the headers of the request; you're meant to cache that token, and supply it every time the user makes a request.
It sounds like you're not caching that token and supplying it when the user makes a request.
You need to store the oauth_token, you can use the same for all requests.
On the FAQ of Twitter API
How long does an access token last?
We do not currently expire access
tokens. Your access token will be
invalid if a user explicitly rejects
your application from their settings
or if a Twitter admin suspends your
application. If your application is
suspended there will be a note on your
application page saying that it has
been suspended.
you need a db tables called user and user_tokens. Inside the user you have: id, user_oauth_secret, user_oauth_token. Inside the the user_token you need this columns: id, user_id, token, created, expires. make sure this token is unique (and long) with some random hash. now you can save this token to the user's cookie and find the right oauth data later.
You need to store two tokens.
When you make the OAuth request the first time, it will show the Twitter auth screen. After auth, your OAuth callback page will get two query string parameters, "oauth_token" and "oauth_token_secret" for the user. You need to store these (probably in a database) somewhere.
Then, when you request OAuth permission again from Twitter, send the two tokens, and the user will automatically be authorized.
You shouldn't have to code this yourself. There are plenty of OAuth libraries out there.
You have to maintain a long session with the user and save the access tokens. Cookies are commonly used to recognize users.