I have two Rails apps, and I would like to accept user login credentials from one app (say App A) in another (say App B). For the app that's accepting login credentials (App B), I think the best option is to use OAuth. But for the app whose user credentials are being used (App A), how do I allow the user's login information to be used by another site? Do I use OAuth as well, or something like Doorkeeper? As you can tell, I'm very new to user authentication, so any advice would be helpful!
One possible way to solve the problem is to create a doorkeeper-based standalone app that would contain all of a user's credentials. Then your client apps would actually connect with this "auth app" (using Oauth.) Then when the client is authenticated on the Auth App, they get returned to the Client app. Of course, from a UI perspective, you make this seamless, so your login page would actually be on this Auth app, but it would look seamless to the user. This way, you can add as many apps as you want and the credentials would all be in one place. To answer your specific question, you would use Oauth2 on your Client apps and Doorkeeper on your Auth App.
You'll need to tweak the doorkeeper configurations to make this process "clean" to the user. For example for internal apps, you can safely use the skip_authorization method in doorkeeper. Learn more about that here
This doorkeeper/oauth system has the added benefit of decoupling your authentication logic from your main application, which is fundamental to good Service Oriented Design. There are certainly other ways to approach this problem, but given the context of your question, yes, Doorkeeper and Oauth2 would solve your problem.
Related
I am using Auth0 for authentication in my app, I've put the login button on the app's home screen , pressing the login button moves the user away from our app and into another location(Auth0 site), and then it takes us back after successful authentication. Is there any way of doing this with Auth0 that you stay within the app itself? That is, the user would not know that the app is using Auth0.
Yes, assuming this is a web app you can use an Embedded Login by placing the Auth0 Lock widget on your page. There are some security hoops you have to jump through if you do that (enable cross-origin authentication, use Custom Domain Names or assume your users have 3rd party cookies enabled, etc.). There's a good pro/con explanation of the two approaches here:
https://auth0.com/docs/guides/login/universal-vs-embedded
Also, there may be some ways to roll your own UI and use the Auth0 API to authenticate. The down side there is you may be introducing some security holes that Auth0 presumably wouldn't (since they're the security experts).
I assume this app is a web application.
In that case you can use a custom domain. You can specify something like login.example.com. Where example.com is your app domain. Please note that custom domain feature is not available for free plan.
I have a simple question about using Pushbullet's OAuth API and was not able to find the answer on PUshbullet's site. Specifically, if I register my client app to use Pushbullet's OAuth authentication and I send my users to give their approval to allow me to use their Pushbullet's credentials, what happens if the person is not already a Pushbullet user? Will they be allowed to register themselves with Pushbullet as a new user (I hope!) AND then be redirected back to my app, or will that kind of break the OAuth flow? I am trying to use Pushbullet as my notifications mechanism for my mobile hybrid app and it seems like it is a great fit, but I know many of my users will not know how to recover if they break out of being redirected back to my web app. TIA.
JLP
New users should be redirected to your app. You should test it yourself to make sure though.
We have an app that has a backend web service. We are looking to implement a user authentication from our native iOS app to the web server. We want our native app to login to the website, get a token to use for requests and expire this token after a period of time (e.g., after 30 days).
We are looking for sample code to show how to do this for a native iOS app.
For example, do we use a UIWebView with the web login url? An advantage of this is that the user registration, forgotten passwords, etc. code for the web is available to the native app. Otherwise, we would have to re-write the registration, account confirmation, forgotten password code for the native app. If we use the web view approach, what do we save in the native app to verify requests from logged in users?
If we re-implement the registration, verification, forgotten password, login code for the native app, what are the things we need to worry about? What is the best way to implement this code? A sample pseudo or real code is appreciated.
My coworker and I just implemented a web view for login into an enterprise app we are building. You have listed many good reasons for this approach, and it works.
I am not an expert in this area, but I will describe what we accomplished in a matter of several days. Hope it helps.
First, the web login page we display is an existing enterprise login system that supports the OAuth2 protocol. OAuth2 is a pretty popular and secure way to support this type of authentication. There is a ton of information about OAuth2 on the web, and it's fairly complicated, in my opinion. The first key to making us successful was having this enterprise login system already available with OAuth2 support. We didn't write any backend code.
Second, we used this open source library to handle the implementation of the OAuth2 protocol in iOS: https://github.com/nxtbgthng/OAuth2Client
As I mentioned, OAuth2 is complicated to implement. The library takes care of most of the complexity, so the amount of code we had to write was small.
Using the library was a bit challenging, but we managed. The library documentation will get you started, but we found this tutorial extremely helpful in getting it all working:
http://www.idmworks.com/blog/entry/getting-started-with-oauth2client-on-ios
Our solution involves a single login view controller which hosts the web view, and a class to manage the keys and URLs needed to configure the library.
With this approach, authentication is handled entirely by the web view. Upon successful authentication, our view controller intercepts the redirect URL and uses the request token it provides to obtain an access token that can be used to access secure resources. The heavy lifting here is handled by library, and our enterprise login system. Our app has relatively little to do. The library stores the tokens securely in the keychain. It also supports a refresh token which allows for silently refreshing the access token, if your backend supports that.
When our app launches, it navigates to the login view controller if the user is not signed in, or to the main view controller if user is signed in.
I'm trying to work out the best architecture for a couple of apps I'm developing.
In both apps I want to utilise google/twitter/LinkedIn/etc to provide authentication of a users identity. The app is composed of an iOS app which has an option to send data to a server which I'm writing in node.js.
I want to utilise either OAuth or OpenId to handle identifying a user against the above servers so that I don't have to put in an authentication system of my own. In other words, allowing users to re-use their ids when choosing to upload data.
I should also note that apart from identifying a user, obtaining a name and email address, I have not intention of using any of their APIs at this time.
I think I have two options:
Place the Authorisation code in the iOS client and transmit some sort of key to the server with the data which it can then verify.
Keep the iOS client fairly dumb, and handle authorisation from the node server.
I'd probably prefer the second option because it means I could centralise authentication and be able to support a web site as well. That's my current theory.
Can anyone who has done something like this give me some pointers as to the pros and cons, OAuth or OpenId, or links to some examples?
In our previous app we opted for a combination of the two approaches. We wanted to centralize our user data on our server in the event we needed to make future API calls on those services. We also wanted the native oAuth experience for the user on the client. Ie: on Android and iOS, the developer can have single sign-on / authorization run through the native Facebook app (if available), vs. popping-up a webview that serves the 'Approve' dialog. It's a better user experience in my opinion. Also for Twitter, the oAuth process may require a PIN code to be entered in the callback which should probably be handled on the client side.
You can pass the access token retrieved by the client to the server for storage and later use if you intend on making additional API calls on these services, provided you expect the token to be long-lived (ie: offline-access permission on FB).
In any case this is mostly a user experience decision.
I asked various questions about my problem (here and here) and I also asked in the #oauth & #openid freenode's channel on IRC. (this is note an "UP" question, it's an other problem)
I'll sum up my project configuration : Anyone will have the possibility to create an app that can use my API. To start, I'll work on my API and a Web based app, but the documentation about the API will be public. It's a bit like Twitter API.
The problem I face is how can I be sure which user is using the API (to retrieve his personal data, like your tweets), even if the User is using an app that I don't know who make it (again, like twitter and all the apps around).
I googled a lot and with the help of the previous answers given, I took a look at OAuth.
As far as I understood the way OAuth works, here how :
A user visit an app that use my API (web, mobile, whatever)
The apps redirect the user to the API for the authentication (I'll use OpenId) and the authorization (OAuth). This is a bit odd since the API will have a web interface for the login and the authorization (I suppose this is how it works since Twitter do that)
The API redirect the connected user to the app, with some tokens. In these tokens, there is a token representing the user that the app must store in order to indicate to the API which user is using it currently (Am I correct?)
So far, everything goes well. But what I can't figure it out, is when the user quit the app and goes again : how the app can remember the user is the one that used it before ?
(Before some of you bring me the cookie answer, I'll remark this is a simple example, it would be the same if the user clear his cookies, format his computer or change its computer.)
The only solution I can find, is when an unauthenticated user (without a remembering cookie for example) goes to the app, the app redirect him again to the API to authenticate himself, but this time, the user won't have to re-allow the app (authorization) since it already did it. The API will then return the user to the app to allow him to play with this.
Is this the proper & secure way to do it ?
The #OAuth IRC channel told me about the new protocol, WebID, but this is currently in pre-draft mode and I don't want to use something that will change continuously in the future :/
Thank you very much for your help!
Short answer: OAuth results in an authenticated access token. That access token is tied to ONE user. And as long as the access token is valid. The third application can do whatever the API allows the access token to do.
Long answer:
The thing with OAuth is that it does not "Log in" a user. OAuth gives third party applications what is called access tokens which can be used to access data on behalf of a user whether he/she is logged in or not.
Many services restrict their access tokens. Twitter for example issues two types of access tokens, read-only, and read/write. But there is no concept of logging in to use APIs. While an access token is valid, a third party application can access the user's data, and change things without a user's explicit interaction.
Most API providers have functionality to revoke access tokens. That is what happens when you in twitter look at your Connections page . See the revoke access links?
Personally I love the OAuth approach. As an API provider, you can control what access tokens are allowed to do, and the user can kill bad applications from using his/her resources. OAuth is secure as far as authentication goes. Third party applications do not get hold of user's passwords. But once authenticated they can do whatever your API allows.
if we take a look at how Twitter works, I think the missing point is an other layer to the project: The Official website:
The thing is, when you want to allow any 3rd party application to use Twitter, this application redirect you to the OAuth page of the Twitter API, IF you are connected, but if you aren't, it redirect you to the login page, which is located at http://api.twitter.com/login
(I don't know if keeping the api in api.twitter.com for loging an user, instead of just twitter.com is correct, but this is just semantics)
So, the workflow would be:
A user goes to a 3rd party application (like a website)
This third party redirect the user to the API for Authorization
The API redirect the User to the website for Authentication first
The official website redirect the User to the OpenId provider (or Facebook connect)
The Authentication is made (via multiple requests)
The website redirect the user to the API after he's successfully authenticated
The user allow/disallow the permissions asked by the 3rd party apps
The API returns to the 3rd party apps.
The User can now use (or not) the application.
This implementation have 2 problems:
Every time an User ins't authenticated (cleared it's cookies, connect himself from an other computer, etc), he will have to go through the Authentication method, by being redirected to the Official website and then being redirected to the 3rd party application (the API would be transparent, since it has already allowed the application to access his data).
All those layers would certainly lost the User on the Authentication process with too many redirections.
A possible solution would be to store the user's access_token, for example in the case of a mobile app, but with a pure html/css/js oriented app, this isn't possible. A login/password in the 3rd party web application that would match the user to the access_token of the API would be an other solution, like Seesmic (I think), but this is just useless (for us, not Seesmic) : the idea of not having the user's password become useless.
This is a possible explanation but I would require more details on how this is possible and your thought about that solution. Would it work?
(I added this as an answer since it's an (incomplete and not so sure, I agree) one.