3 ms·

Also interesting is that OAuth2 is a bit too flexible in how you can put things together and OIDC provides a lot of good practice about that how. So even syste

Also interesting is that OAuth2 is a bit too flexible in how you can put things together and OIDC provides a lot of good practice about that how. So even systems where OIDC compliance is a non goal often are partially OIDC compliant, I mean there really is no reason to reinvent the wheel if part of the OIDC standard already provide all you need.

clhodapp 2y ago
OAuth 2.1 tightens it up a bit. I don't think very many people know that OAuth 2.1 exists, though.
- portaouflop 2y ago
  2.1. is still in draft stage.
  - dathinab 2y ago
    2.1 is mainly updating 2.0 with various later RFCs and usage recommendations, many of them are not drafts. And some document used e.g. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics https://datatracker.ietf.org/doc/html/draft-ietf-oauth-secur... are technically a draft but practically a "life" document constantly kept up to date So while technically 2.1 is a draft, practically not following it means not following best practices of today so while you don't have to meet it fully if you care about security you really should use it as strict/strong recommendations. At least _longterm_ not doing so could be seen as negligence for high(er) security applications. The most important changes are listed here https://oauth.net/2.1/ https://oauth.net/2.1/
unscaled 2y ago
OIDC is still far more flexible than I would have liked. It still allows the implicit flow, and it even created a new abominations that didn't exist in OAuth: The Hybrid Flow. If you just want to follow best practices, OAuth 2.1[1] or OAuth Best Current Practices[2] are far better options. [1] https://oauth.net/2.1/ https://oauth.net/2.1/ [2] https://oauth.net/2/oauth-best-practice/ https://oauth.net/2/oauth-best-practice/
- dathinab 2y ago
  Preferable the intersection of OIDC, OAuth 2.1 and Best Current Practices. As in use OAuth2.1 recommendations including OAuth Best Current Practices to structure you clients inside of the OIDC framework which mostly will "just work" (if you are in control of the auth server) as it only removes possible setups you decide not to use from OIDC. Through I'm not sure if requiring (instead of just allowing) PKCE is strictly OIDC compliant but implementations should support it anyway ("should" as in it recommended for them to do so, not as they probably do so).
  - jogux 2y ago
    "Through I'm not sure if requiring (instead of just allowing) PKCE is strictly OIDC compliant" It's technically not compliant, but people definitely do so, and there are definite security advantages to requiring it. Technically the 'nonce' in OpenID Connect provides the same protections, and hence the OAuth Security BCP says (in a lot more words) that you may omit PKCE when using OIDC. However in practice, based on a period in the trenches that I've mostly repressed now, the way the mechanisms were designed means clients are far more likely to use PKCE correctly than to use nonce correctly.)
- raxxorraxor 2y ago
  Both systems have grown too much and are too complicated. At some point someone will replace it with something easier. I used countless ID providers and while they offer a very valuable service, the flows are too complicated and many implementations have a lot of security flaws because the users don't understand the implications. The implicit flow was trying to make it easier.
- jogux 2y ago
  Yes, indeed. Both OAuth 2.1 & the BCP tighten things up a lot, although neither is technically final yet (the security BCP should be published as an RFC "any day now"). For people looking for an easy-to-follow interoperability/security profile for OAuth2 (assuming they're most interested in authorization code flow, though it's not exclusive to that) FAPI2 is a good place to look, the most recent official is here: https://openid.net/specs/fapi-2_0-security-profile.html https://openid.net/specs/fapi-2_0-security-profile.html This is a good bit shorter than the 50 or so pages of security BCP :) FAPI2 should also be moving to 'final' status within the next few months. (Disclaimer: I'm one of the authors of FAPI2, or will be once the updated version is published.)

clhodapp 2y ago

OAuth 2.1 tightens it up a bit. I don't think very many people know that OAuth 2.1 exists, though.

portaouflop 2y ago
2.1. is still in draft stage.
- dathinab 2y ago
  2.1 is mainly updating 2.0 with various later RFCs and usage recommendations, many of them are not drafts. And some document used e.g. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics https://datatracker.ietf.org/doc/html/draft-ietf-oauth-secur... are technically a draft but practically a "life" document constantly kept up to date So while technically 2.1 is a draft, practically not following it means not following best practices of today so while you don't have to meet it fully if you care about security you really should use it as strict/strong recommendations. At least _longterm_ not doing so could be seen as negligence for high(er) security applications. The most important changes are listed here https://oauth.net/2.1/ https://oauth.net/2.1/

unscaled 2y ago

OIDC is still far more flexible than I would have liked. It still allows the implicit flow, and it even created a new abominations that didn't exist in OAuth: The Hybrid Flow. If you just want to follow best practices, OAuth 2.1[1] or OAuth Best Current Practices[2] are far better options. [1] https://oauth.net/2.1/ https://oauth.net/2.1/ [2] https://oauth.net/2/oauth-best-practice/ https://oauth.net/2/oauth-best-practice/

dathinab 2y ago
Preferable the intersection of OIDC, OAuth 2.1 and Best Current Practices. As in use OAuth2.1 recommendations including OAuth Best Current Practices to structure you clients inside of the OIDC framework which mostly will "just work" (if you are in control of the auth server) as it only removes possible setups you decide not to use from OIDC. Through I'm not sure if requiring (instead of just allowing) PKCE is strictly OIDC compliant but implementations should support it anyway ("should" as in it recommended for them to do so, not as they probably do so).
- jogux 2y ago
  "Through I'm not sure if requiring (instead of just allowing) PKCE is strictly OIDC compliant" It's technically not compliant, but people definitely do so, and there are definite security advantages to requiring it. Technically the 'nonce' in OpenID Connect provides the same protections, and hence the OAuth Security BCP says (in a lot more words) that you may omit PKCE when using OIDC. However in practice, based on a period in the trenches that I've mostly repressed now, the way the mechanisms were designed means clients are far more likely to use PKCE correctly than to use nonce correctly.)
raxxorraxor 2y ago
Both systems have grown too much and are too complicated. At some point someone will replace it with something easier. I used countless ID providers and while they offer a very valuable service, the flows are too complicated and many implementations have a lot of security flaws because the users don't understand the implications. The implicit flow was trying to make it easier.
jogux 2y ago
Yes, indeed. Both OAuth 2.1 & the BCP tighten things up a lot, although neither is technically final yet (the security BCP should be published as an RFC "any day now"). For people looking for an easy-to-follow interoperability/security profile for OAuth2 (assuming they're most interested in authorization code flow, though it's not exclusive to that) FAPI2 is a good place to look, the most recent official is here: https://openid.net/specs/fapi-2_0-security-profile.html https://openid.net/specs/fapi-2_0-security-profile.html This is a good bit shorter than the 50 or so pages of security BCP :) FAPI2 should also be moving to 'final' status within the next few months. (Disclaimer: I'm one of the authors of FAPI2, or will be once the updated version is published.)