I have some questions because I don't understand well how implement authentication flow.
Reading some docs I found image below
Now, I understand the access token and refresh token, but I don't think I understand how to implement it.
I have a project where frontend is angular and backend is node.js koa with microservices architecture and gateways in front of them.
I can use auth0 like oauth2 authorization server with users stored inside?
How? In auth0 docs there are tons of instructions and I cannot understand which is right for me.
I have to intercept login, logout and sign up by gateway and redirect to auth0 or I have to do this inside my user microservice?
Does a user table make sense in my project(s) where there are also personal info table and company table?
Is in this way the authorization server sso for all my company projects?
Can I add external company's SSO?
Can I add Google sign in?
You can follow Auth0 Angular Quickstarts to implement your scenario. It exactly shows step by step implementation. https://auth0.com/docs/quickstart/spa/angular2/01-login
From architecture level, you are doing following:
Frontend application (angular) uses auth0-spa-js to implement Authorization Code flow + PKCE to implement login flow. It simply performs user authentication and obtain a token which request API scope as well. To request API permission, add the audience parameter when initiating the login flow.
Once you obtain the token, access token can be used to call your backend API.
In the backend server , you should implement API authorization (It validates the access token and check token have necessary scopes/ permission). https://auth0.com/docs/quickstart/backend/nodejs/01-authorization
Above API authoriazatio quickstart uses express middleware. This blog post explains how to do the same in koa . https://auth0.com/blog/building-and-securing-a-koa-and-angular2-app-with-jwt/
you have a very broad architectural implementation question for your specific organization case.
I would recommend you follow the below user management model which takes care of
Simple API for Authentication, Registration and User Management using NodeJS + Koa + Passport combination.
You can deploy the API to Heroku and test the API using Postman.
You can use the NodeJS Global Error Handler Middleware and you do not have to implement any reduntant local error handler.
As a best practice, use the node JWT middleware that checks the JWT token received in the http request from the client is valid before allowing access to the API, if the token is invalid a "401 Unauthorized" response is sent to the client. This JWT API authorization can be done at your gateway level itself before your microservices.
Finally the Koa + Passport user service contains the core business logic for user authentication and uses Koa-Redis for session management in the node api, it encapsulates all interaction with the mongoose user model and exposes a simple set of methods which are used by the users controller.
Moroever Koa + Passport supports Single sign-on with OpenID and OAuth which answers your other question related to SSO.
Here too you can find that KOA is best suited for microservices as you have already chosen the same. Overlaying authentication + user management using the same infrastructure will prove to be very versatile and extensible.
https://mherman.org/blog/user-authentication-with-passport-and-koa/
In order to connect to an external SSO provider, you could use the nodejs oauth2 client api as follows which allows you to connect your node backend to connect to an external SSO server.
https://www.npmjs.com/package/client-oauth2
For SSO using Google/Gmail, it is best to use SAML based SSO provided by google.
Security Assertion Markup Language (SAML) is an XML-based framework for authentication and authorization between two entities: a Service Provider and an Identity Provider. The Service Provider agrees to trust the Identity Provider to authenticate users. In return, the Identity provider generates an authentication assertion, which indicates that a user has been authenticated.
SAML is a standard single sign-on (SSO) format. Authentication information is exchanged through digitally signed XML documents. It's a complex single sign-on (SSO) implementation that enables seamless authentication, mostly between businesses and enterprises.
below link provides details of how to setup a SAML/SSO service into google from your application.
https://support.google.com/a/answer/6087519?hl=en
Related
I have to design an IAM solution for a NodeJS microservice using Auth0. Objective is to allow third party mobile application users to access this microservice.
I understand OAuth and OpenID connect solution and one simple solution is third party application accesses APIs as a client using client credentials workflow.
Solution I have to design is allowing users to login and authenticate using their Enterprise IdP connected to our Auth0 Server. So that we can implement authorization and access control at user level.
At the same time customer application needs to be kept agnostic of Auth0 service.
What I mean by it is client should not be required to add any logic in their application for accommodating our Auth0 domain like we have in first party React application. user once logged in to customer application should get access to our API also by using SSO capability. I have read some documents about configuring customer IdP with our Auth0 server acting as a SAML SP. Still I could not understand hows of it and will Auth0 create an OAuth access token in this scenario.
I realise this requires an app to intermediate between customer's mobile app and our API service. Still, I am not able to understand data flow and communication between various components.
Also, I am not sure it is a common situation or requirement? If it is is there any technical term for it? This not seem like a standard B2B scenario.
have to design an IAM solution .. , I am not able to understand data flow and communication between various components ..
Before answering, the answer will points the asked specific questions, may not fit al your needs. SO is not really intended for writing tutorials or searching the documentation. Implementing an IdP (effecively a security module), one needs to do his homework and learn the details.
Maybe using an ready / out of box solution could be interesting. Using an open source IAM such as KeyCloak, WSO2IS could be a quick start. Or cloud services such as AWS Cognito, IBM AppId, Azure AD, .. could be a feasible solution too
a client using client credentials workflow .. access toked received by our API should be for user logged in
The client credentials grant is intended to authenticate only applications. That's it.
To authenticate users, other grant type is needed. For the user authentication the most common option is the authorization code or the implicit grant. The implicit grant is has its weaknesses and is being replaced by the code grant with PKCE (just search it).
End requirement is users of 3rd-party application not required to login again while 3rd-party application fetches data from our API .. Configuring their IdP (most probably Active directory) and our Auth0 servers for the same is all I need to understand
I see most common two options in use:
1. federated SSO authentication
This is the most commonly used option. The external (3rd party) IdP is configured as a "trusted" federated IdP. You often see the scenario when you have a service provider allowing to login with other IdP, often social networks (FB, Google, ...)
The login flow is as follows:
The client authorizes with the provider's (yours) IdP (let's call it IdP1).
IdP1 now acts as as Service Provider with IdP2 (IdP of the partner) and asks for the authorization (redirects the user to the IdP2).
User is authenticated and authorized with IdP2. If the user is already authenticated, the IdP2 doesn't need to ask the user's credentials again, this is how SSO works on this level
IdP2 returns to IdP1 (acting as a service provider).
IdP1 reads the user information (using the id_token, userinfo service - assuming using the OAuth2/OIDC protocol all the time there are other protocols too) and builds its own the user-level token. It may or may not create a local user (it is called user provisioning).
IdP1 returns to the client and the client can request a user-level token.
Then the client can call the API services with the token trusted by the API provider.
2. Assertion Framework for OAuth Authorization Grants
This option is built on top of the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, it is an optional extension of the OAuth2 protocol. I call this a token swap service
Basically the token service could validate the access or ID token of a trusted (partner) IdP and issue its own token based on the provided user information.
As you see there are a lot of information and to build a secure solution you ned to make sure that all steps are properly secured (signature, expiration, issuer, validity, audience, subject domain, .. are validated). Disclaimer - as my job we implement IAM/IDM solutions and a lot can get wrong if shortcuts are taken. So you may really consider using an out of box and proven solution.
I am creating an application with a React front-end and a Java Spring Boot back-end.
My login flow looks like this:
A user clicks on login on the front end
User is redirected to the Google Oauth authorization endpoint on my server
OAuth 2.0 Authorization flow happens: User is redirected to Google and logs in. Google interacts with my server first exchanging an authorization code and then a JWT access token. My server now has the JWT access token for the user.
ISSUE: I now need to redirect the JWT token to my React front-end so that the token can be saved and used every time the user wants to request access to a protected resource on my server.
Is there now an industry standard/best practice for redirecting the token to my React front-end from the server?
There are similar questions on this subject on Stack Overflow, however they are at least 3 years old, e.g. How to provide frontend with JSON web token after server authentication?
Since then the implicit flow has been deprecated, storing JWTs in local storage is no longer recommended, and https://datatracker.ietf.org/doc/html/rfc6750 explicitly discourages passing bearer tokens to the front end in a redirect URL.
I was wondering if anyone knows of an up to date solution for this problem.
There's a draft IETF BCP for OAuth 2.0 for Browser-Based Apps - see here. Basically, it's very similar to native mobile apps using authorization code with PKCE (proof key for code exchange).
FWIW I agree implicit flow shouldn't be used, but IMO you shouldn't be using authorization code flow without PKCE, as this flow is for server side rendered web apps.
EDIT - Auth0 (one of the most popular CIAM solutions on the market) docs say the same thing - see here.
If the Client is a Single-Page App (SPA), an application running in a
browser using a scripting language like JavaScript, there are two
grant options: the Authorization Code Flow with Proof Key for Code
Exchange (PKCE) and the Implicit Flow with Form Post. For most cases,
we recommend using the Authorization Code Flow with PKCE...
Don't.
You seem to mix 2 issues here.
First, you would like to use OIDC for authentication in your SPA. For this you would use OIDC Implicit Flow or Authorization Code Flow with PKCE.
Second, you would like to delegate authentication to google instead of doing it yourself. Basically this is known as federation - you trust external Identity Provider.
The full-blown version would be to setup your own Identity-Provider server (like e.g. keycloak) and configure federation to google there. Your SPA would initiate OIDC against your Identity Provider and wouldn't even know that google did the authentication. You could also easily add further Identity Providers (e.g. facebook) if necessary.
An easier workaround would be to initiate OIDC login from your SPA directly to Google. This way your SPA would receive token directly from google and you would need to protect your own backend as a resource-server accepting and validating those tokens. Adding further Identity-Providers like facebook would be a challenge.
Alright, so I'm having a hard time understanding a proper flow here for my setup.
Goal
I want to have a proper SSO flow for my SPA app that can authenticate users into an API.
Context
I have a React application that is intended to use an Okta porta that offers both SAML (preferred) and OIDC for SSO flows. I've wrapped my static sources in a web server that serves them, and that server has a middleware that checks for cookies, and if one doesn't exist, I redirect to the IDP (Okta) for login. This all works fine for now.
Currently, my API sits on that same server, which I intend on moving to a separate server to scale independently of the website. My API must also allow other machine clients (services) to call into it, so I implemented a service account flow that uses client ID and secret as the authentication measure.
In general, my intended flow looks like this:
User navigates to my website (unauthorized) -> Web Server -> Redirect to IDP -> Assertion Callback flow -> Generate JWT session cookie -> Web Application makes API call -> API Server auth middleware validates cookie / bearer token.
The problem.
The details of how the JWT access token is generated is where I'm stuck. Currently, my webserver receives the SAML assertion and generates a JWT, which is not the same JWT claims logic as the service accounts (bleh). I'm thinking of implementing an Auth service instead to centralize the token generation flows.
For the Auth Service, I've looked into OAuth2.0 and it seems like just the right approach for what I need. With that said, I can't find much information on patterns to follow for SAML assertion -> OAuth2.0. I saw an IETF draft for saml2-bearer grant-type, but it seems dead in the water. I'm also unsure about the general consensus on custom implemented OAuth2.0 grant types.
What does a proper flow look like? I have a couple of scenarios in mind:
SAML Service Provider within the same service as the Auth
Service. On lack of SSO session, my application redirects to my Auth service, which then redirects to my IDP. The IDP calls my SP (the auth server) with the assertion, the auth service generates a token, then my auth service redirects back to the webserver with a cookie placed in the response headers.
SAML SP as the webserver Since the webserver is the only system that needs to use the SSO, I could just keep the SAML flow within that process. Once my webserver receives the SAML assertion callback, my server makes a call to an endpoint service with the assertion claims, and then my auth service returns the access token in a JSON response.
Something else, like OAuth2.0 authorization code flow with PKCE for the web application. Or OIDC instead of SAML for SSO.
OIDC sounds like the right choice for you as APIs are involved. OAuth is designed to secure APIs' compared to SAML which is built for enterprise SSO.
You can integrate your SPA with Okta using OIDC. Okta provides SDK's for varies platforms to make it easier for you to do so. You can find SDKs' here:
https://developer.okta.com/code/angular/okta_angular_auth_js/
Once you get an ID token and Access token from Okta after OIDC flow, you can use the access token to access external API's. Your API resource server or the API gateway can validate the access token. Again Okta provides SDK's to verify access tokens: https://developer.okta.com/code/dotnet/jwt-validation/
I am currently working on a small SingleSignon application. This way, I can save time whenever i make a new project, because the login process is mostly in place from the beginning.
To start with i think I should mention that many off my applications are build on Angular, so I often have multiple applications in one project:
The Angular app (HTML / Javascript)
The REST API (Either PHP or .NET (doesnt really matter))
I have been reading up on OAuth2, JWT and so on, and I understand that:
1) the application authorizes with the SSO API.
2) the SSO API responds (if successful) with an access token.
3) Add the access token to the header, and i have now access to the SSO APIs
BUT
What about my own API that belongs to the application itself? (See the image below for better understanding).
The API for the application knows nothing about the token I recieved from the SSO API, and would of course reject it...
SingleSignon Authorization flow
How would you normally implement this?
Should the application API also ask the SSO api on every request, to validate the token, or how? What would be best practice?`
Thanks
/Dennis
After studying Auth0, I found out that if you are using Opaque tokens (croptographically random string, with no meaning), the token is being verified against the authorization server from the API, as I mentioned in my original post. If you are using JsonWebToken on the other hand, there is no need to contact the authorization server, but check validity of the token by its expiration and signature, AND audience should match the domain of the custom API
So therefore; If you have a custom resource / API, you can benefit from a selfsigned token like JWT, and define the custom resource url in the AUD grant of the token.
Then the resource can validate against the AUD grant.
We're building a public API and clients using this API will need to authenticate, and we proposed to expose an OAuth2 API for this purpose.
However, we also have a need for authentication to be federated, so we see clients talking OAuth 2 with our API, and our API talking OAuth1/2 or SAML2 to the identity provider in the background.
The full flow being:
Client talks OAuth2 to our API.
At the start of this flow, our API redirects the client to a "Choose Your Federated Provider" HTML page.
On choosing a provider, our API talks OAauth1/2 with the provider, passing any redirects back to the client, so the user can provide login details.
Our API exchanges the access code for a access token and refresh token (API keeps these private, and uses them even if the client is off-line).
Our API generates an access code and passes this to the client.
Client exchanges the access code for access token.
The provider supplied access token/refresh token is use by the API in the background, for example to keep a Google calendar up to date, and not passed to the client.
I've not found any examples of this being done with an API. So, what is the established model for providing federated authentication for an API service?
Check out some of the info that Ping Identity provides on their OAuth Essentials page. Specifically, there is a White Paper entitled, "A Standards-based Mobile App IdM Architecture White Paper" (free w/Registration) that you should look at that talks about how you would use SAML + OAuth to secure Native Mobile Apps that require Federation. [Note: I do work for Ping]. It lays out the info flows and token exchanges that need to happen to solve this use case as well as other OAuth related cases.
HTH - Ian