I know how SAML works and I know how OAuth and OPENIDConnect works. I know that SAML is for authentication and OAuth for authorization. but in certain articles it is mentioned that when in 2007 iPhone came in SAML lacked authentication in that case ( for mobile apps ), I am unable to understand that besides delegated authorization, why we needed OAuth to tackle mobile authentication problem ( now being done by OPENIDConnect ) Or how SAML was unable to deal with that issue. can someone help resolve this confusion. Thanks
A few days ago I did this exercise to identify the applications of SAML and OAUTH. I will paste my findings here.
About - SAML
• Authentication
• Authorization (based on claim rules and assertion attributes)
• Mainly designed for the browser based login flow
• Best fit for enterprise applications which rely on centralized user repository
• On-Premise and Cloud application federations are easy (e.g. sync user repository with the cloud replica), user attributes can be passed easily in this case
• Attributes can contain the information(credentials) to connect to another third party application (not recommended)
• Supports encrypted assertion for better security
• Single Req-Res contains the Assertion, avoiding any additional calls to the IdP
• Centralized management of user and authorization data
• Federation metadata involves complex structure, attribute definitions, public certificates, signing algorithms, etc.
• Periodic certificate rollover, CRL management, Claim rules management
About - OAuth
• Authorization
• Requires separate authentication provider (usually coupled with authorization server)
• Best fit for multi-domain, multi user repository scenarios
• Useful in controlling access over individual resources such as account details, file or a service. Temporary/Permanent access can be granted.
• Simple to understand, easy to integrate. Reduces lot of extra work client has to perform
• Resource owner controls the access on resources, can selectively grant access to various functionalities for other applications
• Decoupling of Authentication from the business logic
• Different GRANT TYPE support for different use cases
• Once the token is acquired, SP must make additional API calls to fetch necessary information/resource
• Weak standardization – Every IdP can customize the implementation, which invites customizations at SP side
• Rely solely on HTTPS for encryption, no additional encryption defined for the data being transferred
To Answer your question - Where you will find it difficult to apply SAML
• Inter-application communications
• Backend jobs, Schedulers, business logic where user interaction is not involved
• Communicating with external IDPs which are not managed or controlled by your organization
SAML was not designed for allowing the application to authenticate. It depends on a pre-shared key mechanism for signing/validation, encryption/decryption that is better handled at a server with the attributes being fed to the downstream app in some other manner (like OAuth or OIDC). Can you imagine needing to update a couple million app installs just because the IdP wants to rotate their certificate? Or, worse yet, the IdP's private key gets compromised? Key management in SAML is a difficult enough process, and if you fail, there's a name for the attack you are exposed to - the Golden SAML Attack.
OAuth and OIDC, on the other hand, were designed in such a way thatthe private keys for signing and encryption are expected to rotate regularly. The public keys for decryption and validation are shared on an accessible endpoint by the Authorization Server (AS) or OIDC Provider (OP), which is publicly announced by the AS/OP in the required metadata endpoint. This makes it so that the downstream application that is using the AS/OP can get the keys it needs when they rotate. Generally, the application will cache the keys and use them until failure, at which point it goes and retrieves the new set.
OAuth and OpenID Connect are JSON based and work well in any technology, including web and mobile.
SAML is an older (back end) standard based on XML. It is still widely used in Identity providers, for signing users in.
These days people write apps (UIs and APIs) in terms of OAuth and OpenID Connect - and never use SAML directly. This results in simpler code in mobile apps, single page apps and APIs.
This means the apps interact with an Authorization Server (AS). The AS can talk to identity providers (to support multiple ways to sign users in). This can include integration with SAML providers if required.
See also my recent answer on thinking of OAuth in terms of application capabilities.
Related
I'm just starting to learn about Identity Server, OAuth 2, and OpenId Connect. While doing so I've spent some time looking over the different OAuth flows and their applications. I understand the risks of using the Resource Owner Password Credential flow when the client is 3rd party or not trusted. However, I haven't really been able to find much on its use when the client(mobile app) and api are trusted 1st party. What are the potential risks of using this flow in this scenario? If you could point to specific security vulnerabilities that would be very helpful.
Thanks!
If you are talking about exactly the following...
Your own Mobile App (using trusted libraries)
Collects User Credentials (as if they were logging on your website, assuming you have one)
Sends them over TLS to your Auth server
Returns the normal token response if correct
Then I would argue there is no security penalty, at least, it is no worse than using username/password auth in the first place.
However, there is a wider problem with mobile authentication of this nature.
There is no way to tell that it's your app sending the requests, this applies to all OAuth2 flows (even if you use a more secure flow, the User can simply pull apart the mobile app and extract the credentials).
There are some features from both Google and Apple that attempt to fix this problem, but I'm not sure how mature or secure they are at the moment, it might be worth looking into.
So you are relying on the User to not get tricked into installing a fake app, however, this lands under social engineering and it does apply to all OAuth 2 flows.
There is a food ordering system. There are around 12 or 13 APIs.
The end-user can search for restaurants, foods, filter things, etc. without logging in to the system. The login is only necessary for placing an order, see past orders etc. So, for like 10 APIs I don't need the user to login.
10 APIs (need to verify the third-party)
The rest (need to verify the third-party as well as the user)
The oAuth 2.0 solutions I have seen so far, they instantly asks for the users to login which is something I don't want.
It'd be really helpful for me if someone takes the time to explain a possible solution and how all those could fit together.
If no Authentication is required, then the information is "Public" and does not need protection from OAuth 2.0.
It would not be unusual for a APIs to be called by a WEB Application where the WEB Application needs to use OAuth 2.0 to access the APIs, but the end-user has no relation to the APIs. So the WEB Application needs an OAuth 2.0 client_id for access to the APIs. The client credentials grant is designed for this use-case: (RFC 6749 Section 1.3.4)
when the authorization scope is limited to the protected resources
under the control of the client ... when the client is acting on its
own behalf
The WEB Application may then at some point use OpenID Connect to Authenticate the end-user for access to some of the "protected resources".
I am at a point in a project where I might be needed to bring to table concerns/reasons why OAuth (or even OpenID Connect) should be taken up as the way to go for any future Web and Native Apps over using SAML.
The documentation I have gone through makes the case for the simplicity of OAuth (to which I can attest) but doesn't say it cannot be done in SAML. I've worked with OAuth and I can attest to it's simlpicity but not with SAML that much, but still know that it can be done using SAML, but I think it's way more complicated in that case.
Can anyone point me to an authoritative source that can make that claim and produce any numbers/documentation in favor of OAuth ?
SAML and WS-Fed are enterprise protocols. They have complicated cryptography standards. In the most used profiles, they require browser functionality since the protocol is driven via browser redirects. The token used is a SAML token, XML based and can be large.
If you want to federate with SaaS applications e.g. Salesforce, Workday they only support SAML.
SAML and WS-Fed support SOAP and WCF, no web API.
OAuth is a light-weight protocol suitable for native devices (headless, desktop, WPF), mobile applications etc. There is no browser functionality here so SAML etc. cannot be used. Also these devices are not suitable for complex cryptography
OAuth has a range of profiles e.g. authorization code grant (where OpenID Connect comes into play) and client confidential (that depends on mutual knowledge of a secret key).
It supports web API only.
The token used is JWT - far less bandwidth.
The choice is by use case. One is not "better" than the other.
Refer the scenarios here - Authentication Scenarios for Azure AD.
There appears to be four distinct flows in OAuth2, i.e. (link),
Authorization Code Flow - used with server-side Applications
Implicit - used with Mobile Apps or Web Applications (applications
that run on the user's device)
Resource Owner Password Credentials - used with trusted applications
such as those owned by the service itself.
Client Credentials - used with Applications API access.
If I'm developing a mobile application that will consume resources from its own API, i.e., the mobile app is developed by the same team developing the API, which of the four OAuth flows should I use and how?
Given my scenario, it sounds to me like option 3 is the way to go. If this is the case, would you adopt the following process:
Release you mobile app with the ClientId and ClientSecret stored on
it (deemed okay as the application is trusted).
Ask the user to log into their account using cookie-based
authentication (immediately deleting their username and password).
Cache the hash of their username and password returned in the
response of the cookie-based authentication.
Use the cached username and password, along with the ClientId and
ClientSecret, to request access and refresh tokens from the token
endpoint of the OAuth server.
Doe this seem sensible? It would be good to know if I'm on the right track with the above thought process, or if I'm going something incredibly silly and ought to be doing this some other way.
Resource Owner Password Credentials flow would be okay for your case.
BTW, it is difficult for a mobile application to keep its client secret confidential (RFC 6749, 2.1. Client Types, RFC 6749, 9. Native Applications). Therefore, in normal cases, a client secret should not be embedded in a mobile application. In other words, embedding a client secret is almost meaningless in terms of security.
2- Implicit - used with Mobile Apps or Web Applications (applications
that run on the user's device)
If your application runs entirely on a mobile device then you are encouraged to use this flow as your mobile app can't be trusted to keep its client credentials secret.
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.