I'm trying to get my head around OAuth from the context of having an API that I want to secure and a javascript based single page app made in Vue.js that will consume this API. I've been told that OAuth is the industry standard for this type of thing.
I want to let other clients like a mobile app also use the same API.
From what I can gather the right flow is Authorization Code Flow with Proof Key for Code Exchange (PKCE) https://oauth.net/2/pkce/
The bit I am confused over is how I seem to need to get users to approve access. For example you don't have Twitter saying "Would you like Twitter to use Twitter". If I was in the position of people using the account to create another account I wouldn't have any confusion but when the client is your own website what is supposed to happen?
I can sort of imagine that I could automatically approve the website or just bypass the part where the user approves but then I feel like I'm going off script. Then I think to myself, have I completely got the wrong end of the stick- is OAuth not designed for this?
If anyone can see where my ignorance is I'd be more than happy to be corrected!
Thanks!
OAuth and OpenID Connect enable you to authenticate users in many ways, for web and mobile clients. Each app implements a code flow and redirects to an authorization server (AS).
Each client is configured with an entry in the AS, and consent can be disabled when required. It is typically only enabled when personal assets are involved. Eg to grant a security code scanning service access to my GitHub repositories.
From asking around a bit and reading a bunch more found searching for "first party" providers: it is okay to just have the main website bypass the bit where they approve access and just send over the token.
We are planning to use OpenID Connect / OAuth2 to handle access to a list of resource servers.
We want to use JWT as access token when a user is going to call one of the resource servers. The access token will be issued by an auth server in our landscape according to OpenId Connect / OAuth2 standards. Access will be granted or rejected to the calling user based on the JWT access token.
The standards are new for us so we are still reading and understanding.
We are currently searching for an option to do a lookup of the resource servers with a call to auth server. We would like to use it in order to simplify the clients.
Is there any option available in OpenId Connect / OAuth2 to help clients finding the available resource server? Is there any endpoint available in auth server to do that? Or can the answer with the JWT be enhanced to return the list of the resource servers?
Thanks in advance
Thorsten
With the use of JWT, there is no need to go for one extra validation from the authorization server. Token & its claims should be enough to validate the access rights. You can customized the token claims as per the needs.
An Authorization Server does not know the list of APIs, since APIs are not usually registered as clients. There are some related concepts though. The IAM Primer article has a good overview on how these concepts fit together.
Each API covers an area of data and this maps neatly to the OAuth Scopes included in access tokens.
Each API has an audience, such as api.mycompany.com, which maps to the aud claim in an access token. This can enable related APIs to forward the same access token to each other and securely maintain the original caller's identity.
An API gateway is usually hosted in front of APIs, as a hosting best practice. This enables clients to use a single, easy to manage, API base URL, such as https://api.mycompany.com, followed by a logical path.
My question is quite simple, if you want to integrate social media oauth 2.0 you have to add the callbacks to an application for that specific social media platform such as FB/LinkedIn. Afaik, there's no way to add these callbacks through an API of some sort, correct? Meaning that if I want to add say a 100 callback links to fb, I'd have to add them manually?
To my knowledge, you're correct; it would be a manual process. There are a few specifications that would allow a more programmatic control of this registration information, but the specific provider you wanted to use would have to support them or a custom approach and again I don't think Facebook does it. For reference purposes:
OAuth 2.0 Dynamic Client Registration Protocol
OAuth 2.0 Dynamic Client Registration Management Protocol
Another possibility would be to go through a mediator that integrates with the providers you need to support and that can act as a provider on his own and at the same time allows you to configure the redirects in a programmatic way.
Diclosure: I'm an Auth0 engineer.
An example of this, would be Auth0; it integrates with Facebook and LinkedIn, but then allows your custom application to talk directly with Auth0. The benefit is that you configure Facebook and LinkedIn integration once with a single redirect URL and then can use that configuration acroos multiple applications.
Since Auth0 exposes OAuth2/OIDC endpoints you would still talk the same protocols but could now leverage Auth0 Management API to perform programmatic administration of the OAuth2 client application registration information; including the dynamic registration of redirect URL's. If you use FB or LinkedIn purely from an authentication standpoint this is a real straightforward approach to achieve your requirements. If your required the access tokens from FB to then make calls to their API on behalf of the user, although still possible with Auth0, you have a bit of overhead as these tokens would not be automatically available to your custom applications.
We want to establish SSO between microservice apps,
Eg: In a e-commerce site if user logins to main app,user should be automatically allowed to access cart app connected to it, which is a micro service.
I searched Oauth spec but I could find any relevant answer specific to my case.
some of things which differ wrt Oauth are
User need not to authorize resources(cart app) against Identify provider.it should be done seamlessly in backend.
we don't want to use outside Identify provider like facebook,google,Main app(from eg above) should act as identity provider.
Questions
1.Is there a standard way(procedure) defined in oauth to handle these kind of authentication/authorization.?
If not what are the most popular alternatives ?
Other info:
Ours apps are build using Ruby on Rails,if you know any good gems please suggest.
I found couple of questions(1,2) related to this but they much broader. Even google is also not helping,so please don't mark this question as duplicate.
If you do want to use SSO, let all your services accept the same token, returned by Authorization server when user log in. Encrypt it and put to cookies for example - in this case your web frontend will authenticate user by validating that token against Authorization server and return user-specific content.
The same applies to cart service - it can get username by token and return user-specific cart items.
Pros: User can't access other user's data by design, user logout disables every service.
Cons: You will need "superuser" or additional API for background or analytical tasks.
Before you put me down for asking too basic a question without doing any homework, I'd like to say that I have been doing a lot of reading on these topics, but I'm still confused.
My needs seem simple enough. At my company, we have a bunch of Ruby on Rails applications. I want to build an SSO authentication service which all those applications should use.
Trying to do some research on how to go about doing this, I read about CAS, SAML and OAuth2. (I know that the "Auth" in OAuth stands for authorization, and not authentication, but I read enough articles saying how OAuth can be used for authentication just fine - this is one of them.)
Could someone tell me in simple terms what these 3 are? Are they alternatives (competing)? Is it even right to be comparing them?
And there are so many gems which all seem to be saying very similar stuff:
https://github.com/rubycas/rubycas-server and https://github.com/rubycas/rubycas-client
https://github.com/nbudin/devise_cas_authenticatable
https://github.com/onelogin/ruby-saml
CASino and https://github.com/rbCAS/casino-activerecord_authenticator
And I am sure there are hundreds of OAuth related gems.
I just want a separate Rails application which handles all the authentication for my other Rails apps.
Note: I do not want to allow users to use their Google / Facebook accounts to login. Our users already have accounts on our site. I want them to be able to login using that account once and be able to access all our apps without signing in again. Signing out in any app should sign them out of all apps.
UPDATE
I have come across these two OAuth solutions:
http://dev.mikamai.com/post/110722727899/oauth2-on-rails
http://blog.yorkxin.org/posts/2013/11/05/oauth2-tutorial-grape-api-doorkeeper-en/
They seem to be describing something very similar to what I want. But I haven't found any guide / blog post / tutorial showing how to do this with SAML / CAS.
Suggestions welcome.
UPDATE 2
More details about our use-case.
We do not have any existing SAML architecture in place. Primarily, it is going to be OUR users (registered directly on our website) who are going to be accessing all our applications. In the future, we may have third-party (partner) companies calling our APIs. We may also have users from these third-party (partner) companies (registered on their websites) accessing our apps.
CAS-Server:
A stand-alone central login page where the user enters their credentials (i.e. their username and password).
CAS supports the standardized SAML 1.1 protocol primarily to support
attribute release to clients and single sign-out.
(a table in a SQL database, ActiveDirectory/LDAP, Google accounts, etc.)
Full compatibility with the open, multi-platform CAS protocol (CAS clients are implemented for a wide range of platforms, including PHP, various Java frameworks, .NET, Zope, etc.)
Multi-language localization -- RubyCAS-Server automatically detects the user's preferred language and presents the appropriate interface.
SAML :
Security Assertion Markup Language is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.
SAML authorization is a two step process and you are expected to implement support for both.
OAuth 2.0:
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf.
Important Note :
SAML has one feature that OAuth2 lacks: the SAML token contains the user identity information (because of signing). With OAuth2, you don't get that out of the box, and instead, the Resource Server needs to make an additional round trip to validate the token with the Authorization Server.
On the other hand, with OAuth2 you can invalidate an access token on the Authorization Server, and disable it from further access to the Resource Server.
Both approaches have nice features and both will work for SSO. We have proved out both concepts in multiple languages and various kinds of applications. At the end of the day OAuth2 seems to be a better fit for our needs (since there isn't an existing SAML infrastructure in place to utilize).
OAuth2 provides a simpler and more standardized solution which covers
all of our current needs and avoids the use of workarounds for
interoperability with native applications.
When should I use which?
1.If your usecase involves SSO (when at least one actor or participant is an enterprise), then use SAML.
2.If your usecase involves providing access (temporarily or permanent) to resources (such as accounts, pictures, files etc), then use OAuth.
3.If you need to provide access to a partner or customer application to your portal, then use SAML.
4.If your usecase requires a centralized identity source, then use SAML (Identity provider).
5.If your usecase involves mobile devices, then OAuth2 with some form of Bearer Tokens is appropriate.
Reference 1,Reference 2,Reference 3
If you need to authenticate for LDAP or ActiveDirectory then a solution like one of the CAS gems you mentioned above is right for you (RubyCAS, CASino).
If you can afford it, one of the commercial vendors (like Okta) is your best option because they will stay on top of security patches and manage your authentication needs for you. In particular, if you have to support ActiveDirectory, they've already implemented it.
OAuth is most useful for third party authentication, though it can do SSO. So if you wanted to support Google / Facebook logins or be a third party authenticator then it's a great choice. Since you don't want to support Google / Facebook then OAuth is probably not what you want.
If you are only intending to use HTTP POST for your SSO needs then the ruby-saml gem could be the way to go. You would have to implement your own Identity provider and add a service provider component to all your websites (possibly in the form of a gem.) Part of what you would need is a rails api to act as your identity provider. This gem helps support writing API's in rails.
EDIT
You mention the possibility that future third party users might be logging on to your site. This changes your calculus away from rolling your own ruby-saml solution.
The best way to share your authentication API is to implement an OAuth layer. Doorkeeper is a popular solution and is fast becoming the standard for Rails authentication. It's community support, flexibility and ease of use make it the best way to go for a consumable authentication API.
Railscast for implementing doorkeeper
Anjan.
I've used CAS and OAuth in my work. Here are some of my opinions, and hope to help.
Basically
Both CAS and SAML aim to solve SSO situation. And CAS is a service or an authentication system, which can support SAML protocol.
OAuth aims to solve authorization and authentication.
And in practice,
Both CAS and SAML act as an gateway in front of a group of applications which belong to one organization. Just like your case.
OAuth is used to authorize and authenticate between different organizations.
Just my thoughts, and hope to hear more voices.
We have used CAS and SAML in our architecture (Mobile App, Online Portal, and MicroServices) and both are used for different purpose.
Our Online Portal is like online banking that runs in public domain and has to be secure. We don't want to store password and other secure token's in the DB of the online portal, therefore, we use CAS for authentication and authorization. During registration, when user chooses the password, we store the password in CAS and store corresponding token in the DB of Portal
When user login next time, User enters the user name and password in Portal. Portal fetches the token corresponding to user from DB and sends User_name, password, and token to CAS for validation.
But, in case user has already logged in into one application and we redirect user to our another application then we dont want to user to enter username and password again for second application. We use SAML to solve this. First application shares user details with SAML server and gets token in return. First application passes the token to second application. Second application sends token to SAML server to get user details and on success lands user to desired page. Our first application can be Mobile App and second can be Portal in the scenario of App2Web.
Since you have got lot of answers for this question, I would like to suggest you an identity product that can be cater these kind of all protocol in one hand with lot of authentication and user management features. You can just try WSO2 Identity Server version for this.