How do we allow a second client to authenticate users and access our api authorized backend? Please correct any part of my understanding that is incorrect.
User authentication is register / login / logout portion of your app.
App authorization for an api is confirming your app has permission to access an api.
A user should be logged in to the app and the app should be authorized in order for the user to access the api.
It is important to keep user authentication separate from app authorization because different clients (apps) may access our services through our api. Accordingly different users may have different access rights.
Consider a simple web app. Rails with devise is used in the app (api client) for user authentication. The app then accesses the rails-api using doorkeeper for app authorization.
Consider then adding a simple mobile app. How would the mobile app access the same user authentication service? How would we allow mobile app access to our user authorization service?
Would we need to separate the user authentication service into its own api using a separate instance of doorkeeper to authorize the mobile app and web app before creating users and then after authenticating users again authorize the app plus logged in user to access the backend api?
I'm sure it should be easier than described. Any resources, books, videos also appreciated.
If I understood your question correctly, what you are a looking for is a Service Oriented Authentication. Basically, the authentication provider could use Devise + Doorkeeper. Then the consumers could use omniauth-oauth2.
A good tutorial on oauth2: https://www.youtube.com/watch?v=zTsyeMV-N0c
Rails specific implementation: https://www.youtube.com/watch?v=L1B_HpCW8bs
Cheers!
Related
Our OAuth client application is built with Spring (through JHipster). The OAuth provider only serves the authentication functionality, but not the authorization functionality. Ideally, we should only allow a small group of people to access our OAuth client application, but not all those users who can sign in to the OAuth provider.
A solution I can think of at this moment is to create a custom user role to control the access in the OAuth client application. That, however, only can be done after the user's first sign-in when the user account data is created in the application.
Any better solutions?
Ideally you would apply user access control before creating user account data is created in the application. You could do so by providing an application specific scope or claim in the token that is generated for your application (aka. Client). Upon receiving the token, the application would check for the required attribute in the token before allowing access.
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.
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.
How do I secure my API when I want an app to be able to retrieve app-specific information without a user logged in and when I have an OAuth provider for another section of my API? Can I use the client app's OAuth credentials to hit the API without a user logged in?
I have create an OAuth provider and client using doorkeeper following railscasts 353. I can successfully authenticate a user to my provider app and make requests on behalf of the user to my provider API.
However, a portion of the API is user independent, meaning that the information returned from the API is not specific for a user and therefore a user should not have to be logged in. For example, assume an ecommerce site and items and prices are stored on the provider for multiple clients. I want a client app to be able to securely retrieve the items/prices associated the retrieving app without a user having to be logged in. So if you went to example.com the items would be displayed even if a user is logged in via OAuth.
I have only be able to retrieve this information via OAuth when a user has logged in through OAuth (creating an access_token). Is there a way to use OAuth without having a user present (I've been trying to read about 2-legged OAuth and if that is an appropriate solution)? Or do I need to use Api keys (or Http Basic Auth) for the application to retrieve the application specific data?
If OAuth is not the right solution because I do not have a user present, could/should I use HTTP Basic Auth over SSL and use the client site's OAuth secret key as the API key for the basic auth username?
If you need to authenticate your client apps in you API (without requiring a user specifically) use the Client Credentials flow
I'm developing a facebook app with rails that uses external apis from my own domain. The problem is that my domain requires authentication, which is done via oauth. It's not clear to me how to deal with this pattern. I'm not sure I can make oauth calls from a facebook app, thus requiring two separate registrations. Is there a way to pass a facebook access token so that I know the user is authenticated through facebook?
If you are using (or can use) Rails 3.0+, devise has a good section on how to authenticate via facebook or a google account.
Once a user has used this method to authenticate to your webapp, their session is handled in the same way a regular login session is, so you can just use current_user.nil? or user_signed_in? helpers to determine if the users are authenticated or not.