We have a client application we would like enable SSO via OIDC. The client app is an SPA with a dedicated back-end API. Currently, authentication is implemented via cookies and authorization is enforced at the back-end based on the user of the Auth_Cookie. After the OIDC authentication completes, we would like to continue to leverage these existing local cookie-based code/logic, which also avoids the need to store the tokens with the SPA.
Upon completing the Auth Code PKCE Flow, the front-end SPA would have received the ID_Token and Access_Token directly from the OP's /token endpoint. To get from ID/Access_Token to Auth_Cookie, an approach could be:
/authenticate), passing the Access_TokenSince, the ID_Token is meant only for the client app (which is the front-end SPA in this context), my assumption is it has no role in this sequence (though logically, you would think a call to the back-end API's /authenticate endpoint should supply something resembling credentials, e.g. ID_Token).
Does the above approach make sense and are there any security issues/concerns with it? Are there alternative/better approaches for essentially converting the front-end OIDC authenticated context to cookies?
Any insight or help would be greatly appreciated. Thank you.
I think it would be easier to make your backend process the auth redirect - to make it an OAuth2 client instead of your SPA. Your SPA doesn't need the tokens and there will be no need to transfer access token to the backend. The backend handler, which would receive an auth code, would get tokens and create the auth cookie (with all security params).
If you need to keep your SPA as OAuth2 client, then your proposed solution is probably good.