Hacker News Reader

Comment by ratiolat | Hacker News Reader

From adminstration and user perspective Oauth (Oauthorization) is alot more confusing though.

"Why is google asking me to grant access to my google drive for SAAS X, I just want to login to SAAS X via Google"

You can't compare OAuth with SAML. OAuth is authorization and comes only ever after authentication, which is OIDC.

But to respond to your critic: It is good that apps let you know that you are IN FACT not merely logging into something, but grant that app access to your Google Drive. This is a very important information! Imagine your mom signs into ClashOfClangs (a malicious clone) and the IdP would in fact NOT tell your mom that the app will have access to all her files because it may be confusing

This sounds like a complaint with Google's implementation, not with OAuth in general. The correct scopes should limit information sharing to the user's profile. All of the security and privacy concerns that necessitate an explicit user interaction apply to SAML too.

That's the thing - authentication capability is basically sideeffect of Oauth/OIDC. SAAS x can request whatever they want via OIDC and then user can either accept it or decline it. This is protocol, not google specific matter. Ask ordinary user how they understand what is being asked from them when they are trying "to log in" via OIDC/Oauth. With SAML it's the other way around - administrator chooses what is being sent to SAAS x, user does not need to decide anything nor do they get hard to understand prompts.

I'd say the main difference is that OAuth is granting the SP the ability to "do stuff" as the original user (including reading the user's profile details, as OIDC does), as opposed to SAML's approach of just sending attributes describing them.

For what it's worth, it is certainly possible for SAML SPs to flag that certain attributes should/must be released to them via their metadata, but the actual release is at the whim of the IdP and its operators. It's also possible for a SAML IdP to expose that level of detail to its end users and allow them to agree/disagree to the attribute release, although I'd be surprised if that behaviour was particularly common in practice.

The difference between OIDC and OAuth boils down to exchanging attribute assertions describing a user as opposed to the delegation of a specific set of allowed actions, as OAuth was intended to do. OIDC and SAML are basically the same thing, with OIDC being a somewhat less frightening and more modern protocol.

Reading the user's profile information _is_ the delegated action. OAuth providers were already doing this prior to OIDC but in incompatible ways. OIDC standardized how that information is requested and returned.

No, the whole point of OIDC is that permission to read your profile is not semantically the same thing as authenticated sign-on.

Should, but don't. OAuth2/OIDC implementations tend to be way more transparent about the asks being made between an IdP and SP. It can be confusing. (I agree, however, it's the right path.)

Reply on news.ycombinator.com