1

I'm going to apologize in advance for the rambling nature of this question, I've read a lot about SAML and OIDC and other standards, just trying to understand why browsers seem to be so essential for them.

I've been doing some reading and research into different Authentication and Authorization flows (SAML and OpenID Connect to be specific).

Assuming I am building a web based application that uses some other provider to do the authentication (Okta, Ping Federate, etc), both SSO using SAML and OIDC seem to have flows that involve redirecting to the IdP to provide the actual Authentication for the user.

Afterwards, SAML seems to use further browser redirects to perform the Authorization for my own server, whereas OIDC can use REST API calls using the exchange token or access token or whatever without needing browser redirects anymore.

My question is: why must the browser be used with the IdP when doing the actual Authentication. I understand that the only way to ensure the user's credentials are not stolen along the way is that the IdP has absolute control over it and never exposes it to any other apps involved. But are there any generally acceptable and modern standards that involve, say, just REST API calls or some way that doesn't involve browser redirects? For example, I write my own page to capture the username/password, that I then POST to an IdP.

Or is the general consensus that the Browser must redirect at least once to the IdP in order to verify that you are even authenticated, and then if the requesting page is allowed to use the user currently authenticated in the IdP.

TL;DR: Is there any Auth standards that doesn't require a browser redirect to the IdP, or do all generally accepted Auth standards require it?

1 Answer 1

1

The SSO protocols redirect the browser to the IdP because the browser must receive the WebSSO session cookie from the IdP's web server (same origin). Otherwise it would not be single sign-on and the user would have to type in the password for each application login.

There are two variants regarding the actual session data provided when redirecting the browser back to the application (service provider, short SP): - mostly older protocols only provide a one-time session-ID and the SP checks that against the IdP, optionally retrieving some more user attributes - newer protocols also include user attributes in a integrity-protected message (e.g. digitally signed) during redirect to SP

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .