We are developing an application in a microservice architecture, which implements signle sign-on using Spring Cloud OAuth2 on multiple OAuth2 providers like Google and Facebook. We are also developing our own authorization server, and will be integrated on next release.
Now, on our microservices, which are resource servers, I would like to know how to handle multiple token-info-uri or user-info-uri to multiple authorization servers (e.g. for Facebook or Google).
This type of situation is generally solved by having a middle-man; a single entity that your resource servers trust and that can be used to normalize any possible differences that surface from the fact that users may authenticate with distinct providers. This is sometimes referred to as a federation provider.
Auth0 is a good example on this kind of implementation. Disclosure: I'm an Auth0 engineer.
Auth0 sits between your app and the identity provider that authenticates your users. Through this level of abstraction, Auth0 keeps your app isolated from any changes to and idiosyncrasies of each provider's implementation.
(emphasis is mine)
It's not that your resource servers can't technically trust more than one authorization server, it's just that moving that logic out of the individual resource servers into a central location will make it more manageable and decoupled.
Also have in mind that authentication and authorization are different things although we are used to seeing them together. If you're going to implement your own authorization server, you should make that the central point that can:
handle multiple types of authentication providers
provide a normalized view of the user profile to downstream resource servers
provide the access tokens that can be used by your client application to make authorized requests to your microservices
Related
Trying to understand how multiple IDPs can work together within a SPA.
My initial thoughts
User login with the default IDP and acquire the IDP1-JWT.
When the User needs to Access IDP-2's resources, he accesses through a reverse-proxy over IDP2.
The reverse-proxy send the sub(subject) and sid(session-id) to IDP2.
IDP2 negotiates with IDP1 (openid-connect) to provide the required token.
Reverse-proxy sends IDP2-JWT to IDP2 microservice to enable resource access.
I am still very confused that the above scheme is even sensical, or if there are standard ways to facilitate this kind of exchange. Are there any ways that two OAuth servers can exchange information?
Will this even work for SPA, since IDP2 and IDP-Resource-Server2 would have different domains?
What are the security risks I should look out for?
Thanks
Trying to use Keycloak as IDP2 (which is more under my control) with the steps https://keycloak.ch/keycloak-tutorials/tutorial-token-exchange/#configuring-token-for-an-identity-provider
I have used spring security in the past and understand that most of the features of keycloak can be achieved by using spring security ( ldap integration etc ).
Apart from easy social media login validation, are there any other unique features in key cloak which cannot be done using spring security?
With spring-security you would have to create Spring authentication server and explicitly configure/code certain things for integration with LDAP, OAuth2/OIDC providers.
Keycloak is already OAuth2/OIDC/SAMPL compliant IAM provider. It provides features like User Federation with options like LDAP, integration with other OIDC provider etc.
Keycloak provides SPI integration points where you can customize the request flow, use OTP, perform two factor authentication, add google CAPTCHA, or even your CAPTCHA. It provides role based authorization too if you need.
It also provides event handling integration points for events like Login, logout, refresh token, etc.
Keycloak Community will keep adding new features or keep supporting it w.r.t. changes in OAuth2, OIDC, SAML. You don't need to worry about updating your code time to time. Along with this, security updates will be there.
There are many more features.
Most importantly, why reinvent the wheel, if you get these many features and good support.
Keycloak allows you:
to use multiple user storage and get users from multiple LDAP/AD or Kerberos or use without any LDAP.
to login once (SSO) and forget about to login from another application with GUI;
to use one authorization server for multiple application by separation them by realms. One thing should be noted: keycloak could be installed on multiple nodes for better reliability; This also could helpful when application become big and once you decide to separate it on multiple.
to add user additional attributes and fields during get user info without coding (trivial example - set phone number) or specific roles (on realm or even client level) or groups and use all this on the top of an AD attributes;
to configure password rules like password expiration, e-mail validation and so on;
to set up 2-factor authorization with SMS or Email.
These things I think could be implemented using Spring Security, but it takes more time than Keycloak installation and configuration. Personally, I am using Keycloak in multiple commercial projects and could claim that Keycloak is good.
I'm developing an authentication/authorization system in Node Js for a microservice based application.
I read some articles and documentation about the OAuth2 standard but I need some clarification for my use case.
Basically OAuth2 has some actors like:
Resource owner (user)
Client app (a web application in some OAuth2 grant flows like authorization code, implicit, password)
Authorization server
Resource server (service I want to access to)
So in my database I store a client (web application) with its client_id and client_secret.
Let's suppose that one of my microservice needs to access data from another microservice. Both of them espose a REST Api.
There is no interaction with user, all is done in the background. In this case I would use the client credential flow.
Following OAuth2 rules, both of them are resource servers but in the same time it looks like they are client apps as well.
So should I register them in the client DB table/collection with client id, secret etcetera or did I make some mistakes?
Thank you
If I understood your question correctly, the caller micro-service is your client and the one that is being called is your resource. A lot depends on what type of micro-service communication pattern have you implemented. If you are implementing an "API Gateway" pattern, then your Gateway is always client and all other micro-services can be treated as resources. But if your micro-services can call each other then like you mentioned each one of them have to be registered as client and resource at the same time.
I believe the short answer to my question is "No", but allow me to describe the context.
We are currently using IdentityServer to authorize access to our APIs (via client credentials). All of the API clients are computer programs which run in our data centers and are under our control. In order to minimize our attack surface, our IdentityServer is running from an internal/private network, reachable from our APIs, services, and other apps. No problems.
We now want to leverage the IdentityServer installation to provide user authentication for our public-facing web applications. These applications run via ASP.NET MVC and will consequently require user interaction with the IdentityServer for password validation (implicit or hybrid grant type). This appears to be a hard requirement, but I'm curious if there is a simple way to maintain the private installation of IdentityServer.
Can we proxy requests from the ASP.NET middle-ware for handling the authentication handshake, and does it even make sense to do so? I'm leaning towards a public-facing STS to eliminate any proxying, but thought I would ask to see what other patterns are employable.
For what its worth, we would ultimately use cookie-based authentication with the hybrid flow, but would be able to start with the implicit flow too.
The user's browser must be able to access the identity server. This can be via a proxy though.
I'm going to be undertaking a large project for a client of mine. I need to write an IDP (identity provider) that will handle single-sign-on to multiple apps by a number of different authentication methods (such as SAML, OAuth, Form-based auth, HTTP Basic auth). I'd also need the ability to add in additional types of authentication as the app grows.
The basic idea would be that we'd have three different components to the app. One would be the IDP. Another would be a data-store that contains user accounts, the apps they want to use, etc. The third would be a GUI front-end that allows users to sign into apps.
It seems that there are some existing gems that handle authentication, like https://github.com/onelogin/ruby-saml and https://github.com/intridea/omniauth. My question is, am I overcomplicating this project -- would I just be able to use existing gems like these to act as the IDP, or is this a project where I'd need to read specs and implement them myself in Ruby?
Using something like SAML toolkit for Ruby on Rails adapted to work with ADFS server, you can integrate with ADFS. Now you can leverage ADFS features:
Interface with Facebook etc. via Azure ACS
Interface with Azure Active Directory and hence SSO to SaaS applications
Azure Active Directory Multi Factor Authentication
BYOD via the Web Applications Proxy
OAuth on ADFS 3.0
and so on. The list is expanding all the time.
Once you hook into these standards. you just inherit all the new features as they are released.