Re:OAuth 2.0 Security Best Current Practice
by anderspitman on Tuesday May 05, 2020 @02:40PM
(#23083276)
At least one problem is that Oauth2 isn't a protocol; it's a framework for making protocols. Things like endpoints, scopes, security practices, etc aren't prescribed, so every implementation is different. And unfortunately none of the big players are really incentivized to standardize anything.
[ Parent
| on HN ]
Re:OAuth 2.0 Security Best Current Practice
by ecnahc515 on Tuesday May 05, 2020 @05:11PM
(#23085109)
OIDC is basically a protocol, and is what you're describing. It's _the_ attempt to standardize on a common set of scopes, discovery mechanisms, etc for making it easier to build apps that use OAuth2.
And the platforms that do support OIDC properly just require a login portal URL to integrate support for it.
Want to add Microsoft logins with an oidc library? One url.
Want to add Twitter / Facebook signin? Go get an OAuth library and write several hundred LOCs to detail the scopes and crap you want form them because they are non-standard.
Re:OAuth 2.0 Security Best Current Practice
by anderspitman on Tuesday May 05, 2020 @05:48PM
(#23085472)
Forgive me if I'm mistaken, but isn't OIDC for authentication/profile information? Does it include standards for things like accessing contact lists, reading/writing files, sending email, etc?
OIDC is for authentication and profile information. The standard claims refer to each field of profile information [1].
It doesn't include any domain-specific operations like your examples.
[1] https://openid.net/specs/openid-connect-core-1_0.html#Standa...
Re:OAuth 2.0 Security Best Current Practice
by ecnahc515 on Tuesday May 12, 2020 @07:42PM
(#23161500)
A bit late: you're correct, but it does provide a standard API for looking up additional metadata, even if it's non-standard. That's using custom claims and/or the user info endpoint (which can include custom claims). You can use custom scopes to limit what is available as well.