I am currently working as system integrator for a banking company, that asked me to provide an authentication integration on a third party website on which the company would like to redirect users, but recognizing them as already authenticated.
For many reasons, they don't want the third party to be integrated on the origin domain identity provider (as a standard OAUTH2/OIDC flow).
I was thinking on this flow:
- Let's call origin domain a.com and target domain b.com
- The user authenticates on a.com and on some page he is going to have an hyperlink, something like https://a.com/go-to-b. This resource is authenticated following a.com authentication system, so the request would be a GET with a bearer token issued for a.com
- Behind that resource there is an a.com server-side endpoint that recognizes the user U as authenticated and issues a new token for U with an RSA256 algorithm and a private key PRI-K (different from that issued for accessing a.com/* resources)
- The endpoint then calls another endpoint GET https://b.com/auto-login with
Authorization: Bearer PRI-K - We will ask b.com domain owner to implement the GET /auto-login endpoint in this way:
- The call is authenticated checking the bearer token with the public key related to PRI-K
- If authentication is ok, on first access, the user is registered
- After that, the server resource issues the internal token B-KEY for b.com and redirects with a 302 to a landing resource https://b.com/my-website setting the session cookie with B-KEY
Do you think this flow is reasonably safe? Can it be simplified in some way?
