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.
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.
At my company we are developing several web applications that uses a REST API server.
First a little introduction.
The app provides the ability to manage users through the REST API and allows the users to login to the app.
Right now the REST API is for internal use only because we plan to develop more apps and communicate to the REST API as the central point of data access. We are handling the REST API authentication with a "Resource Owner Password Credentials Grant" implementation for the internal apps.
What we need is a Single-Sign on service for all the apps, we want a user to login to an app and if he/she access to another of our apps he/she will be already loged in.
We have been experimenting with the CAS protocol, with the CASino library specifically and it works great.
The problem is we don't know how to handle the flow between the apps, the REST API and the SSO service, also I don't know if there is a better choice regarding SSO services.
My questions are...
How we could handle the flow between the apps, the REST API and the
SSO service, because the REST API should be stateless it should not
communicate to the SSO service? or is there a way to communicate the
REST API to the SSO service?
Is there a better choice to implement a Single-Sign on service,
maybe OAth or OpenID and are this options suitable for REST APIs?
Thanks in advance!
Your REST API will have to talk to the SSO server to validate the Access Token, unless all the information it needs is encrypted inside the Access Token. Not sure what you mean by "flow between the apps", you should have all apps talking to a central SSO server.
When a user wants to create an account on WebApp1, the account should be created on the SSO server, either by redirecting them there or if you need a differently styled signup form for each web app, then via an AJAX call to the SSO server's REST API. I would recommend the latter as redirecting is more difficult to debug and it can make a bad user experience.
Make sure the messaging is clear, i.e. not "Sign up for a WebApp1 account", but "Sign up for a MyCompany account to get access to WebApp1".
OAuth 2.0 is very popular and people have more experience with it, so it's easier to get help or integrate with apps created by others.
The doorkeeper gem is a good server library.
OAuth 2.0 is normally used when the SSO server doesn't trust the client apps (e.g. Facebook, Twitter), but it can be implemented in such a way to skip the client authorization step (where the user is asked to approve the client app), and you can use the Resource Owner Password Credentials Grant via a REST API.
CAS is easier than OAuth. It is fairly easy to implement the basic endpoints and that way you can customize it as you wish.
I worked on a CAS-based server with a custom implementation (not sure if it was even really CAS-compliant). The authentication was done with Devise (I don't recommend Devise if you're going to customise it a lot, make your own in this case). The original flow was that the user went to the website, clicked Login/Register and then was redirected to the SSO server and after the user logged in, redirected back with a one-time ticket that the website's backend exchanged to an access token via a REST API call.
Then we added a REST API that was called from each website with AJAX. You send the username/password/captcha/etc and get back an auth token, which the site sends to its own backend. The SSO REST API can also set a cookie on its own domain, so that if the user visit another of our web apps it makes a call on pageload to check if the user is logged in. This way you're automatically logged in on every webapp without the redirect mess.
All tokens issued + the associated user info were sent to a fast Node.js app that would save them to Redis, and the app backends would call this app to validate the access tokens really fast, without putting load to the SSO Rails app.
We're working on a new API that we wish to secure with api tokens. These tokens are tied to a user and an application. These 3rd party applications use OAuth to authenticate themselves (using and app_id and app_secret). This works great.
However, we have our own mobile app which will also consume this API. Obviously I'd like to avoid having the user get asked the familiar "would you like to allow this app to use your account" when performing a login. Obviously we can't embed a secret in the app, (hence pure OAuth would be unsuitable for this). However, I don't want to create an API endpoint to which a username and password can be sent since this would effectively bypass the OAuth scheme entirely.
On the web site, we can just dump the api token into the DOM after a regular form submission, and allow the Angular app to use it from there; but this simply isn't practical in a mobile app.
So my question is; how can we securely identify login requests from our own mobile application? How does (for example) Facebook know that it's the Facebook app supplying the username and password when authenticating, and not some 3rd party application?
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.