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.
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.
I am about to embark on adding a 'post to Twitter' feature on a web application.
It appears 3-legged OAuth is the only option for this. The developer documentation states however that "The user will always be prompted to authorize access to your application, even if access was previously granted."
https://dev.twitter.com/oauth/3-legged
This doesn't seem like a very good experience for the user and confusingly this is not what happens on services like Hootsuite. Have they organised an agreement with Twitter so users don't have to keep authorising the app?
Use the Sign-in With Twitter flow, and store the access token that the user receives when they grant access to your app. Then there's no need to go down the oauth/authorize route every time.
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 creating an app for iOS that consumes an API I've created, which requires authentication and authorization of users. I'm thinking of using OAuth to let the mobile users do this with Facebook. This is an internal API that isn't meant to be exposed to third parties.
Anyway, I'm a little confused about the abilities and limitations of OAuth consumers versus OAuth providers. Basically, I want to implement "Login with Facebook" functionality from the iOS app. It seems to me that this implies that my API should be an OAuth consumer, but the problem with this is that the login flow for a web app assumes a browser -- an NSURLConnection instance isn't going to know what to do with an HTML login page, and even if the redirect to the login page was made to work by prefixing the redirect URI with the fb:// schema, surely the login form is going to pass the authorization token back to the iOS app and not my API?
So my question is: is there a way to implement my API as an OAuth consumer? If not, and I should implement it as an OAuth provider, what does logging in with credentials from another provider like Facebook even mean?
I think things are a bit mixed up:
OAuth is to Authenticate your app against facebook. A user grants
access to his FB account to your app on behalf of him
"Login with FB" is the other way round and is not OAuth: A User
with an FB account is using this data to register AND login to your
app.
The entire flow of the # 2 can be read here.
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.