We have a working REST API which uses OAuth2 password grant (for access through our own Web UI) and client credentials grant (for scripted access), and may allow other grants in the future.
Recently a request came up to support 3rd party Single Sign On through OpenId Connect (so we can support identity providers such as Google and LinkedIn, but also some of our client's internal SSO systems that support OpenId Connect.
I'm trying to understand how to integrate the OpenId Connect flow into our existing authentication, authorization and identity management architecture.
One important thing is our system still needs to control authorization and access token grants and expiry. We just want to allow 3rd party authentication and identity management as an option, from a selected (but flexible) list of providers. Basically the way I see it, OpenId Connect can, optionally, replace the password grant for some users.
Can anyone recommend a guide or a reference implementation for such setup? Am I trying to do something that doesn't make sense?
EDIT: By "existing architecture" I mean our own existing user database, which supports email / password based authentication (that using OAuth2 password grant). We want to maintain this DB / authentication flow but also allow 3rd party OpenId Connect based authentication.
Related
We have in my organization an existing ASP.NET web application built in a SAAS model that our customers (users from different organizations) login through username/password authentication method. Users' credentials are hashed and stored in our database. We are currently working on adding a SSO feature to our application that would allow end-users from certain organizations to login with SSO using their own Identity Provider (Azure AD, Google, Okta, etc.) to perform the user authentication. We are using the OpenId Connect protocol to establish the SSO connection with IdP, and more specifically the Open Web Interface for .NET (OWIN) middleware. We have implemented the following:
Our SAAS application offers customers the ability to opt for SSO authentication through a setting. End-users from these organizations will be authenticating to our application via SSO AND using their own IdP
Our application supports SSO connection from different IdPs (Azure AD, Google, Okta, etc.)
Our application stores SSO connection settings for each customer that opt for SSO authentication (Client Id, Authority, Secret, etc.). All these settings are configurable in our application, they're available upon registration of the application on IdP side.
My question is about the app registration. I know that in order for our application to communicate with IdP and initiate SSO authentication it needs to be registered on related IdP, so that it can create a trust relationship. I am wondering which party should be responsible of the app registration:
My organization owner of the SAAS application? or
Our customers willing to use SSO authentication method?
With option 1, my organization will have to have an "account" on each of the IdPs our customers use for authentication (I feel this is not ideal for us), register our application and have a mechanism to invite our customers IdP to connect to the registered app.
I feel like option 2 would be the best approach for us as we won't have to deal with app registration, as customers will be responsible of registering the application on their own IdP. From my organization end we will just need to deal with SSO connection settings (Client Id, and other...) which will be provided to us by our customers upon app registration. I wanted to check if this is a common situation that some have already experienced, and what would be the best/recommended approach to go with. Thanks.
I am expecting app registration to be performed on customers side.
I would usually recommend that your internal services and APIs only need to trust tokens from one Identity Provider, and in your case you have one openid connect provider inhouse. That then supports your users to authenticate to and optionally authenticate using an external provider, like how the image below tries to show:
In my experience, having your applications trust and handle tokens from multiple sources will be a pain, as many of the external tokens might look slightly different.
I'm part of a small team as a nodeJS dev and I've been tasked into researching how this can be accomplished. I'm fairly new to OAuth and authentication so please bear with me.
Currently we have a next.js webapp that uses NextAuth for authentication with the user store in DynamoDB. What we want to do is provide an Oauth2 flow so a user can consent to a 3rd party service having access to their profile information via an endpoint. In this case we are the resource server, the 3rd party is the "client" and our user is the resource owner.
The piece of the puzzle I'm trying to put together is how does Auth0 work with NextAuth in this scenario? I want Auth0 to check if the user is logged in (otherwise prompting them to do so) via NextAuth, and for NextAuth to say "this is fine" and then for Auth0 to issue a token to the 3rd party (concluding a "normal" OAuth flow). Is this were SAML comes into play? I see there's a software package called SAML Jackson (lol) and there's a Next-auth integration for it.
Most examples I see usually work the other way around, with Auth0 as the identity provider, and what we're doing may be unique. Sorry if this question comes across as abstract but that's how it exists in my mind currently. Any help understanding this would be greatly appreciated.
You can connect your user store to Auth0 as a custom database connection. And then create an application inside Auth0 and enable the DB connection for the app. This way Auth0 acts as the Authorization server for your client app.
NextAuth.js is just an authentication library that supports the OAuth2.0/OpenID protocols. The role of NextAuth is simply to initiate the authentication flow, take the user to the Identity Provider (in this case Auth0 backed by a custom user store) and finally process the authorization response from Auth0. The authorization response (code) is received at the application end and then exchanged for access_token and user profile (all handled by NextAuth.js).
And for your query on SAML, it's a standard for exchanging identity information between two parties an Identity Provider (IdP) and a service provider (SP). The same is achieved by its more modern counterparts OAuth2.0/OpenID Connect. Typically third-party apps which are deployed in an enterprise setting use SAML to integrate with on-premise Identity Management Systems like ActiveDirectory. You can read more about SAML on https://boxyhq.com/blog/understanding-saml-sso-the-basics-from-the-user-side.
We are running some tests on Keycloak to implement it on our company and I am are wondering what is the best approach to make Keycloak interact with our legacy system.
In our scenario, we have a native login interface and we are going to use direct grant - we are not going to authorization code flow / redirect flow using a browser and we don't have any kind of social login.
The other point is: we must to keep our native interface.
Based on that, what is the best/right approach to implement this flow? I have set my client on Keycloak with direct grant but the problem is that every user must exists in Keycloak. Isn't possible to use Keycloak as a "token emissor" instead of IDP?
In case of Keycloak must be an IDP, what is the right approach to allow Keycloak log in legacy system? Should I implement a custom Identity Provider? Will mobile make a login request to Keycloak or to legacy system?
Keycloak must somehow be able to either authenticate the user or delegate the authentication of the user to a federated identity provider. A few options:
If you want to use Keycloak as an identity provider, you could do
this by migrating your user base to Keycloak, or by making use of
User Storage Federation, which means Keycloak will use your existing
user database as a source. In this case, the login interface will be
a Keycloak interface (which you can customize to your wishes). See:
https://www.keycloak.org/docs/latest/server_admin/#_user-storage-federation
Another option is to convert your legacy system into an identity
provider that complies with either the OIDC or SAML protocol, and
set it up as an identity provider for Keycloak. In this case you can
keep your existing login interface, but it will probably require
quite some changes to your legacy system. See:
https://www.keycloak.org/docs/latest/server_admin/#_identity_broker
We're planning integration between two services: A and B.
The service A is going to be an OpenID Provider, the service B relies on it to log users in and create new accounts.
The service A also provides access to its resources via REST API using OAuth authorization, the service B uses the OAuth Access Token obtained via OpenID Authorization Code Flow.
However, there are some cases when A wants to get data from B. There is an established agreement between these services, that A can access any data from B in the scope of a user that was created via OpenID Connect.
How could I design authorization for the service B API? What could A provide to B in an HTTP request?
I'm considering things like a classic API Key, but it doesn't look natural in this workflow.
There are no direct solution to your mentioned scenario from OAuth and OpenID Connect protocol perspective.
But from what you have explained, you have OAuth 2.0 access token protected services in service A. Also, A acts as an identity provider (with OpenID Connect support). If this the case, I believe you control token issuing process and validations.
One options is to enable services from B , which are protected from OAuth 2.0 access tokens. Which is similar to what you already have in A. And to consume those services, you will have some service/client implementations bound to A. What they would do is obtain tokens from A itself to communicate with B. This can follow client credential grant from OAuth 2.0 as there is no end user involvement (scenario involve service to service interaction).
This suggested solution is similar to API key usage but with added benefit of OAuth 2.0 protocol.This allows you to generate Access tokens with limited life time and allow refreshing them if required. Also, in case you want B's services to be consumed by another client, then things are straightforward.
I know that both the federation protocols can be used to manage user identities.
Basically for Gmail based login, I want to know the benefits of using OpenID Connect over SAML.
OpenID connect is simpler JSON/REST based with compared to SAML. Apart from this is there any benefit of using OpenID Connect for Gmail based authentication?
It depends on what you call "GMail based login".
1- if you mean let my users read their mails on GMail using their credentials maintained in my internal organization, OIDC and SAML will do the same. This is simply not the same protocol. So, depending on your internal directory (Active Directory, NetIQ eDirectory, openldap, /etc/passwd, etc.), it may be easier to use one of these protocols.
2- but if you mean connect to GMail with my application, on behalf of my users, only OIDC will let you do that, because of the underlying OAuth2.0 mechanism.
OIDC means authentication and authorization, SAML only means authentication.
Historically, SAML and WS-Fed were used for enterprise connections and are browser based.
OIDC is for mobile and can be used via ADAL for native devices i.e. non-browser based e.g. dektop applications.