We've got implementations in a browser-based system right now that does both SAML and OpenID-connect login support, but does them differently and was looking for advice on the risks.

Our SAML implementation does a full browser redirect to log in - it completely leaves the SP site, goes to the IdP, and the postback goes to an API endpoint that validates the response and responds with the application's authentication token. Of course, that postback is done via the user's browser as per the protocol.

The OIDC implementation uses a child window - the app (the RP) stays on the page but opens a child window which redirects to the OIDC OP; the user does their login and such and then redirects back to a static page. This page, in the browser, extracts the code and state from the response and posts that information as a message back to the parent window (the RP page). This parent page then sends the code and other info to the back end, which does the code->token exchange and performs the validation.

From an ease-of-use perspective, the child window behavior is preferred - we can use a static redirect URI with the OIDC response which makes configuration easier. I was curious if we could do the same with SAML; I think it's fine, the SAML response has already been in the browser once to handle the redirect from IdP back to the application, so managing it in the browser for another hop should be no different.

Conversely, is there a risk of passing the OpenID Connect code around between windows on its way to the back-end? Is it safer to have that OIDC response go directly to the back-end over HTTPS? With the code being opaque and short-lived, and with the other validations all happening using secrets only available to the back-end, it seems like it's not any less secure.


You must log in to answer this question.

Browse other questions tagged .