I am new to oauth 2.0 and reading up on it. I tried using oauth 2.0 for my app with 37signals site and ran into a problem. Now sure if its as designed. Any here is what I see.
User is already logged into 37signals site.
My app starts the oauth flow by redirecting him to 37signals site
An authorization page appears asking the user if he is okay with granting access to my
app.
User approves and is brought back to my app. (An access token
is also available)
Now, user logs out of 37signals site.
User tries to use my app. My app starts the oauth flow by redirecting him
to 37signals site.
The user logs in using login screen.
He is again shown the authorization page. Shouldn't this be skipped since
the user approved it the first time? Or is this as designed?
Anyway, this does not seem very user friendly to me i.e showing the approval page every time after logout.
I noticed similar behavior with twitter as well. I initially posted a similar question while using a nodejs oauth library. Then I thought its a general oauth 2.0 question.
everyauth always triggers authorization
Upon initial authentication, the authentication provider, in this case 37Signals, will provide an authentication token. In company with your application key, you can use the users token to authenticate them subsequently, following the initial authentication. It's customary for OAuth providers to expire authentication tokens over time, in which case you would need to have your user re-authenticate.
Related
I am confused about the different login methods and the impacts on the user experience.
I would like to do native mobile app login on iOS, that means the user is not redirected toward the web page (or in app browser tab) to login. For example : All banking applications (Ex: N26) the login method is always the same : User enter his login / pwd and then he connects.
However, when I see the "Best practice login app for mobile" I can see they use authenticate + authorization code flow with PKCE. But using this method, my mobile app has to be redirected to the authorization server (Like when we want to connect with google).
So my questions are :
Is is possible to do native login using authorization code flow with PKCE without opening an in app browser tab ?
In terms of security, authorization code flow is better than native ? If yes, why all banking mobile applications are not using it ?
if the authorization server is the same than the resources server, is it possible to not have this redirection for the login ?
For now, my server use OpenID, tomorrow maybe OpenIDConnect.
Thank you for your answer :D.
Context
N26 as well as most banking apps do not support Single-Sign-On (SSO).
Auth code flow + PKCE is a way of securely having your user login with SSO, usually using a well known Identity Provider (IdP) as Google. Then, assuming your selected IdP follows the OIDC specs, you will be able to receive an idToken which will represent the user who just logged in and some of her details (called token claims) like her email, name, etc.
Answers
Auth code flow + PKCE is related only when you use OIDC SSO, not with native login.
In order to implement a native login you would have to be the "authority" who keeps the data required to authenticate users like email, password etc. Otherwise, Google (or any other IdP) is responsible for that. SSO provides better UX (as long as the redirect to the IdP is not poorly designed) and users prefer it since they are usually already logged in to their IdP, thus they do not have to remember and type credentials. However, the reason that lots of banks do not use SSO is that they do not trust Google. If Google gets compromised, the malicious party would be able to issue tokens that would allow them to impersonate anyone. Same for availability. If Google goes offline for some reason, users will not be able to login. I guess banks believe that they can provide better security and availability guarantees on their own.
Again, you need the redirection only when using SSO OIDC. If you are not using that, and end up using a native login no redirection will be needed. That being said, it is a good practice too keep your authentication server separate to your back end.
As background, I'm using the Google OAuth2 NodeJS client, but I think my question is more abstract / technology independent.
My website is single-page application that communicates via AJAX to the server.
When a user first visits my website, I perform an OAuth2 flow which redirects them to Google to log in, and then redirects back to my site with an access token. I store this access token in a cookie, and use it to handle various calls made to the server via AJAX.
My challenge is that I'm unsure what to do when that access_token expires. Should I be storing the refresh_token in a cookie as well, and using that, or are there security issues in doing so?
Should I be redirecting the browser to perform the login flow again? That seems fairly ugly for a single-page application.
You can do the OAuth2 flow via js in the background(like the login flow with the popup window), and if the access hasn't been revoked for you app id, then the user shouldn't see anything about it. Although you can set a hint on the user email to authenticate, this may not work.
The other way that you mentioned, is the refresh token, that you can use to ask for a new access token, without user interaction. Maybe that would be the better idea, but remember, that you will only get a refresh token if you set the access type to offline.
I am in the process of designing an app that is supposed to let you login using either a username/password combination or facebook login. We have a custom OAuth server that uses user credentials to authenticate users. Now, the question is how to add facebook into this.
As I see it now, when the user wants to login with facebook, the client does all the work and gets the access token in the end. But how do we let our server know that this access token is a good one (and corresponds to a user in the database)? To me it seems like our OAuth server should be able to handle this as well, and I'm just missing the how.
OAuth supports different scenarios (flows). Client-does-all-the-work is so called "implicit" flow.
In your case it would be better to use authorization-code flow and extend your OAuth server. You put a "Facebook" button on your login page and instruct Facebook to redirect to a new special page on your OAuth server. Delivered authorization code then can be exchanged to the access token inside of your OAuth server and the server may issue its own session and tokens based on this.
I'm using Rails to write an API for mobile application and OAuth seems like a standard way to handle user authorization.
If I understand Doorkeeper docs correctly it requires user to be signed in with the website before it grants access for the mobile app.
The issue in may case is that there really isn't any website (it may be in the future but for now it's just api). I would like the user creation/signing in etc be handled in the ios application.
This makes me wonder if OAuth is the correct solution here?
The OAuth "Resource Owner Password Credentials Grant," according to rfc6749 Section 4.3, will grant an authorization token and optionally a refresh token given user name and password. Thus the mobile app doesn't have to store user name and password to gain authorized access. It becomes like a long running session using token and refresh token. OAuthClientSetup an iOS example that runs against a doorkeeper api.
So there is the OAuth method for gaining authorization without having web site login authentication and access grant.
What is left is how to register new users from your mobile app. Agree that does not look to be covered by OAuth. OmniAuth will let you register a user authorized by a third party site. You allow the user to be the user they are on Twitter or FaceBook, StackOverflow or GitHub or wherever else. Maybe that would help.
Imagine the following scenario.
User visits a site A (ASP.NET), authenticates using ADFS and gets a set of claims . At some point, they need to register for an additional service so they are redirected to a provisioning site B (ASP.NET) (also using ADFS – so SSO) where they register by entering their relevant details and are redirected back to A.
However, part of the provisioning process added attributes to a repository (normally AD) and we would like those attributes to form part of their claim set.
To do this they have re-authenticate? Is the best way to do this by forcing a federated logout? Would this be done by site A or site B?
If they are internal users using WIA, they would be logged in “behind the scenes” and the whole process would be transparent.
What if they are external users using FBA? Wouldn’t they have to log-in again? Given that this is not a very satisfactory user experience, is there a way around this?
There are some references out there that talk about writing a signed token as a cookie to the client browser and then the STS later authenticating the SSO token from the cookie. How would you do this with ADFS?
Have a look at the blog post I wrote about a similar scenario:
Refreshing Claims in a WIF Claims-Aware Application
In this case, the user is logged out locally but then redirected back to ADFS where they are "signed back in" since their ADFS cookie is still valid. This little hop is mostly transparent to the user and will update the claims.