0
votes

Experts!

I have created a Node.JS web app with two APis. One of the APIs is GUI where the end-user sees the GUI. The second API is the auth guard that will go and talk to 1L using OPENID > authenticate > fetch user profile and render information to the GUI for the end-user.

We originally wanted to use SAML assertion (SSO) similar to Zendesk or Others that when someone is authenticated to 1L and you navigate to the site domain.zendesk.com the established logged in token just redirects you to the site. When you are not logged in to 1L and you go to the site you are redirected to 1L for auth then redirected back to the site of choice once you successfully auth.

Our application does not have a user database, instead, we are banking on 1L to do authentication for us and also pass through user information to our second API so that we can then pass specific end-user details from the internal side to the GUI. The end goal is to be able to authenticate with 1L and be redirected to the sales.cbac.com and be able to know user specific details about the current user, but that user is to never have to access the login page

Right now, we had to spin up a login page that will accept user info > sends info to auth guard to call 1L auth > returns valid user and user profile info > all using OPENID.

What is the best approach? It seems like we are missing something.

API URL1 (GUI) - sales.cbac.com API URL2 (auth guards - OPENID) - sales-api.cbac.com Current state you land at sales.cbac.com > presented with login page > auth then directed to site

1

1 Answers

0
votes

Your best approach is to consider support for OpenID Connect. Your GUI node.js page requests authentication and recieves an OpenID Connect token ( id_token ) from Onelogin. Info on how to do this is available from standard Onelogin documentation

Then you can use that returned id_token, containing basic user information to make an authenticated call to your API, with your API being responsible for validating and verifying the Onelogin issued token. You have options as to whether to retain the same audience for your GUI and API, or to have specific applications created in Onelogin for your the GUI and API, with each having a separate aud ( audience ) value.