I have spent days researching into both technologies but I am still confused.
Thanks
Saml 2.0 is an older standard, invented before single page applications, REST APIs and mobile phone apps. It focuses on web application single sign on and single sign out.
OpenID Connect does web apps too, but adds support for SPAs and mobile apps and handles API security. So in many ways OIDC is the more capable of them.
There are however some things that SAML2 can do that is not in OIDC:
Federations, where one central entity presents an aggregated metadata file containing information about many Identity Providers and applications (Service Providers). InCommon in the US is one. The new European eID system eIDAS is a SAML2 federation too.
Idp initiated sign on - where the Idp is a kind of application portal. Note that this opens to session pinning attacks and is sometimes not appropriate to allow.
Application (Service Provider / Relying Party) metadata that allows the Idp to be configured by importing metadata describing the application.
Note that API security is offered in the SAML2 specs, through the ECP profile but hardly anyone uses it and there are very few implementations.
Related
We want to build a central authority to do authentication and authorization for our various applications (.net). We see IdentityServer4 is open source and free, while Auth0 cost money. Does anyone use both of these? Can anyone provide suggestion which one to choose and why?
IdentityServer is a library that implements various authentication (not authorization!) protocols and let's you consolidate access control into a single system. You can host it in a typical ASP.NET webapp, console app or anything else, as long as the HTTP endpoints are available. It also lets you store the user data anywhere you want, whether in-memory, databases, flat files, the asp.net core membership system, or anywhere else.
Auth0 is a company that provides a managed service that handles authentication for you. They run the infrastructure and provide access through their website and APIs. It's similar to having someone run IdentityServer4 for you and there are several competitors like Okta for Devs, AWS Cognito, Azure AD B2C, Google Cloud Identity/Firebase, and more.
Choose IdentityServer if:
You want free open-source software.
You have the time and effort to run it yourself.
You want to control the backing data store (SQL database, Redis, JSON file, etc).
You want to manage all the data yourself due to regulations, privacy, etc.
You need complete control and flexibility around what happens during authentication (for example, merging user accounts in your database when someone signs in). It's all just C# code so you can do whatever you want.
Choose Auth0 if:
You want to save time and effort on implementation and operation.
Price is not an issue (as it can get expensive for some features).
The limited customizations offered by Auth0 are enough for your app.
You want the other features they offer like password-breach monitoring.
You don't want to manage user data, or don't mind having it stored by them.
Update as of Oct 2020 - IdentityServer is now a product from Duende Software with a new commercial open-source license to sustain development. There are other alternatives like OpenIddict that are still free.
Identity Server means building a server application to handle authentication and authorization, which can replicate what Auth0 does for OpenIdConnect (OIDC) there will be a few things to implement even if you use IdentityServer4. You will need to build that first, then integrate your application.
Auth0 allows you to integrate immediately with OIDC with additional & enterprise features.
Both of them implement federated protocols i.e. WS-Fed, SAML and OpenID Connect.
In order to use them your apps. need the appropriate client-side stack.
If they don't have this, you can't use the products.
The only alternative is pass-through, i.e. Auth0.
Or look at ADFS which has pass-through via the ADFS WAP.
If you do have the stacks, both will do the job.
idsrv4 does not have a user management portal e.g. create user, add group to users OOTB.
Auth0 does.
idsrv4 essentially adds features by code. Auth0 has config. via wizard.
idsrv4 is open source so you can customise to your heart's content. I find it really useful to bridge systems.
Azure AD is another option.
What's the difference between WS-Trust, WS-Fed and SAML 1.1/ 2.0 protocols?
My understanding on these protocols gets confused when SAML is used as a security token in WS-Trust and WS-Fed protocols.
Interested in knowing in which scenario these protocols used and what makes them different. Your answers will be easy to understand if NO commercial product/ technology references used.
At a high level, WS-* protocols traditionally were used by Microsoft.
SAML-P (P for protocol) was used by the open source movement and hence Java.
WS-Fed has two profiles - active and passive. Active is for WCF (WS-Trust), passive is browser based (WS-Fed via login page).
Both of these use SAML tokens.
Functionally, both WS-Fed and SAML do the same thing wrt. federation
If you federate two ADFS (Microsoft IDP) together you use WS-Fed. If you add in Sharepoint, it also uses WS-Fed. The tokens passed are in the SAML token format.
If you have a Java application that uses Spring, then that will hook in to ADFS via SAML-P. The tokens passed are in the SAML token format.
this question is old but i struggled finding a correct answer online.
A lot of online posts say, that 'passive / browser' clients use WS-Fed and 'active / smart' use WS-Trust. That is probably because the active use case uses by default a url like '/ws-trust/2005' or '/ws-trust/v1.x/'. This does not seem to be 100% accurate. The great and free book: Claims-based Identity, Second Edition helped me with the issue and I finally found a satisfying answer:
The goal of many of these architectures is to enable federation with either a browser or a smart client. Federation with a smart client is based on WS-Trust and WS-Federation Active Requestor Profile.
These protocols describe the flow of communication between smart clients (such as Windows-based applications) and services (such as WCF services) to request a token from an issuer and then pass that token to the service for authorization.
Federation with a browser is based on WS-Federation Passive Requestor Profile, which describes the same communication flow between the browser and web applications. It relies on browser redirects, HTTP GET, and POST to request and pass around tokens.
SAMLP is just a different protocol when it comes to how things are communicated such as the redirection URL and so on, but the differences are not relevant (in most cases) and simply depend what the client supports (e.g. Java will use SAML). The biggest difference is in my opinion that SAMLP allows an Identity Provider initiated Use Case (which is the most secure one in my opinion), where the User starts on the Identity Provider (e.g. the Web Proxy of your ADFS Server, =Claims Provider in MS terms), instead of starting at the Web Service and then getting redirected to the Service Provider (=Relaying Party in MS terms). Also when we are talking about SAML we usually mean SAML 2.0 while WS-Fed uses SAML 1.x Tokens (and MS calls them Tokens, SAML calls them Assertion... its just a signed and possibly encrypted XML, I think theoretically you could use other Tokens in WS-Fed then SAML but i have never heard of anybody actually doing that).
I am currently working on a mobile application that will allow a user to sign in via username/password (OAuth 2.0 Password Grant), Facebook, Twitter, or Google. The backend for this mobile application is coded in Spring Boot/Cloud (Java) and makes use of Microservices principles. I have several small services that are discoverable via Eureka and make use of Spring Cloud Config for centralized configuration. They are all exposed to the Mobile device using Spring Cloud Zuul, which acts as a reverse proxy. The Spring Security OAuth 2.0 setup that I have takes in the username and password then returns a JWT token, this token is validated every time a request is made to the backend. I also store users locally in MongoDB and make use of Method Level Security. I want to add Social Login to my application and have it do the following:
On the Mobile Device do the OAuth dance and get an access token
Send the access token to the server, and using Spring Social create a new User locally and associate it to Facebook/Twitter/Google, and then return a JWT token that can be used to validate requests
This JWT token should be created by Spring Security, and I should still be able to use Method Level Security and have local users
Basically I want all the features I have with my custom Spring Security OAuth 2.0 Password Grant with Social Login
This is my first attempt in architecting a system, and therefore am looking forward to responses from those with much more experience than I have. I have seen many examples that use Spring Social, but all of them are for Web Apps, not for Mobile, this is where I am currently stuck at.
The questions I have are the following:
Is my suggested approach adequate? Are there other approaches that are stateless and better for mobile applications?
Is Spring Security OAuth 2.0 and Spring Social Security enough to accomplish this? If so, are there resources that I can use? I have not found many online.
Could Spring Cloud Security be used as a solution?
Should I consider using a 3rd Party provider for Authentication such as Auth0 or OKTA?
using OAuth2 for a stateless solution is in my opionion adequate, because of:
oauth2 in general is a protocol designed to be usable in every client, which is able to perform http requests. Since the social nets you mentioned all support OAuth2. If everything goes bad, you still can consume them manually respecting the oauth2 specs, which they implement.
in general I see a problem with "authenticate with XXX and use that token as JWT for my requests". This is not directly possible, because that token is for their resource servers. Instead you need to separate 2 processes: authentication and authorization. In short you can use the socials endpoints to authenticate a user in your backend, which leads to a second oauth2 generation from your authorization server. This can create a JWT using all features from spring-oauth.
This libary should used in addition, since it helps to setup a application wide security solution. As example, you keep an own authorizationserver (which authenticates using social login) and several resource servers. spring-cloud-security helps to build things on top of that, as Zuul SSO, hystrix+ribbon powered feign clients respecting oauth2 authentications and so on
I don't thing this will help you, because those services primary serve you as an identity provider, while you are going to couple your users identity over social networks
I hope I could clarify your question in some way
I have achieved it by referring two spring example applications. Check this
steps, you will be able to achieve social sso login with Zuul, Auth-server and multiple back-end REST projects.
Active Directory Federation Service and IdentityServer3 are both STSes that allows Single sign-on to software systems.
I read that IdentityServer3 can use smaller (than SAML 2.0 in AD FS) JWT tokens and can be highly customizable like using different user repository.
But if I have all users in Active Directory and I can accept this bigger tokens and provide resources using AD groups will I have any benefits using IdentityServer?
In my system architecture I want to have WebAPIs connected using ESB. I will have different types of apps like mobile, Angular, desktop. I would like to use solution that will be more reliable than flexible.
Web API normally implies OAuth. ADFS 3.0 has limited support for this. ADFS 4.0 has the full stack.
ADFS 4.0 wrt. web API is functionally the same as idsrv.
Also ADFS in some cases does support JWT.
I am building a cross-platform mobile app that interacts with a RESTful API, and I want to use OpenID Connect to authenticate my users. I will be building my own OpenID Connect provider server.
OpenID.net claims that:
OpenID Connect allows for clients of all types, including browser-based JavaScript and native mobile apps, to launch sign-in flows and receive verifiable assertions about the identity of signed-in users.
However, I can't find any documentation explaining how to actually authenticate for a mobile app client.
This StackExchange answer makes it clear that OpenID Connect does not support the "resource owner password-based grant" flow or the "client credentials" flow.
That just leaves the "authorization code" flow (normally used by server-side apps) and the "implicit grant" flow (normally used by client-side apps). Both of these seem to rely on redirecting the user to the provider's authorisation endpoint, and having the provider redirect back to the client URL. I don't see how this can apply to a mobile app.
Can anyone explain to me (or even better, point me at a tutorial or some example code) which explains how to do this?
Update
To clarify: OpenID Connect relies on the client redirecting the user to the Authorization Endpoint, and then the provider redirecting the user back to the client. In the case where the client isn't a web app, how can this work?
Mobile apps, at least on iOS and Android, can register custom URL schemes so that a redirect from a browser can send the user back to your app along with some query parameters.
So, you can use these flows in a native mobile app, but it involves sending the user to a web browser (either an external browser app or a web view built into your application) in order for them to authenticate with the OP.
A complete article presenting how to implement the "Authorization Code Grant" flow securely on a native mobile app is available here : Building an OpenID Connect flow for mobile. It is based on latest IETF OAuth 2.0 Security Best Current Practice.
Please also note that the use of the "Implicit Grant" flow is now highly discouraged.
I think that the Hybrid flow from the OpenID Connect spec is probably the one which you want to use. OpenID Connect Core Spec.
This does rely upon having a configured return URI, but as James says you would use a custom URI scheme to enable the mobile OS to redirect after login to your own app. Your app would then have an access code which it can use to obtain access tokens as needed (assuming that you are using Oauth2 to protect your back-end API services which the mobile app uses).
There is a vulnerability which would allow a malicious app to hijack your URI scheme and grab the tokens, There is a draft spec to overcome that Proof Key for Code Exchange by OAuth Public Clients which is worth considering implementing.
Using an app scheme URL is the correct answer as noted above. I wanted to add additional clarification since some responses above include links to an article that makes incomplete assertions about a compliant SSO design, and make it unnecessarily complicated for a simple SSO use case. I think google's model is secure and so I might model OIDC interactions with a homegrown IDP after how theirs works.
https://medium.com/klaxit-techblog/openid-connect-for-mobile-apps-fcce3ec3472
The design in this article linked above, as depicted in the diagram on the article, does not work for google's oAuth/OIDC implementation on Android. There are two reasons for this:
Google will not vend any client_secret for an oAuth client that is typed "Android"
Suppose I switch to "Web" application which does have a secret: Google will not allow a redirect_uri other than 'http' or 'https' for an oAuth client that is typed "Web"
Instead, google officially recommends letting the typical mobile flow (and you should also be using PKCE) drop an ID Token on the client, who can then exchange it for a session with the App server:
https://developers.google.com/identity/sign-in/android/backend-auth
This is secure because your IDP should be signing the JWT ID Token with a private key so it can be validated by your system's apps/services and used to assert validated (unexpired) identity intended for a particular OIDC client & audience.
** Do not pass ID Token as authorization on every request, but rather exchange it once with your backend for a secure session context as managed by your application.
Check out MITREid project on github:
MITREid Connect
This project contains an OpenID Connect reference implementation in
Java on the Spring platform, including a functioning server library,
deployable server package, client (RP) library, and general utility
libraries. The server can be used as an OpenID Connect Identity
Provider as well as a general-purpose OAuth 2.0 Authorization Server.