Open4

OIDCプロバイダはnOAuth対策のために `email` クレームを使うなと言ってるのか調査

okuokuokuoku

https://b.hatena.ne.jp/entry/s/speakerdeck.com/melonattacker/jwtsekiyuriteiru-men

そういや nOAuth 脆弱性ってあったな。。

https://www.descope.com/blog/post/noauth

nOAuthが成功するためには、被害者の組織のAzure AD(Entra ID)のadminが悪い人である必要がある。adminは組織のユーザーの email を自由に設定できる。このため、 email をユーザーの識別に使用しているようなサイトで悪い人やその仲間が自由にログインできることになってしまう。

... つまり、OpenID Connect的な意味のID Tokenのコンシューマーの一部には、 全てのclaimがIdPによって検証されていると 誤解 していた ということになる。我々プロは当然そういうことの違いを認識しているわけだけど、ドキュメンテーションが良くない可能性がある。

okuokuokuoku

MS(Azure AD)

今年の6月に直接的なガイダンスを出している。

https://msrc.microsoft.com/blog/2023/06/potential-risk-of-privilege-escalation-in-azure-ad-applications-ja/

https://learn.microsoft.com/ja-jp/azure/active-directory/develop/migrate-off-email-claim-authorization

また、ドキュメンテーションでもその旨追加している:

https://learn.microsoft.com/ja-jp/azure/active-directory/develop/claims-validation

https://learn.microsoft.com/ja-jp/azure/active-directory/develop/id-token-claims-reference

いやアカウントIDとしてe-mailアドレスを使いたいんだけど。。

これは超FAQで、MSのリプライが良く要約している:

https://learn.microsoft.com/en-us/answers/questions/812672/microsoft-openid-connect-getting-verified-email

Emails are unverified in enterprise systems like Azure AD and can be set programmatically to any value by the tenant administrator.
...
Note that even in social sign in systems (like Facebook, Google), the email claim should not be used for authorization decisions. If they do perform email validation, it is often a one-time validation of the email address. There are many email systems where email addresses get reused (employees leave, new employees sometimes get the same email address, same with students at universities). It is also common for emails to change at companies due to personal situations (marriage, divorce). Emails often change during mergers, divestitures, rebranding of companies. All of these situations will invalidate a "1-time" email validation performed by a social provider. It is an insecure means of validating the user.

よって常識的なシチュエーションでは、 email claimを受けとった後、サイト側でリンク操作をしている筈なのでそれを使えということになる。

okuokuokuoku

Sign-in with Apple

https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api/authenticating_users_with_sign_in_with_apple

email_verified claimを提供している(常にtrueを返却する https://developer.apple.com/forums/thread/121411 )。つってもこれは アドレスがreachableかつユニークであることを保証するものではない (proxy addressであっても真になる) ので結局リンク操作が必要になる。

If you request the user’s verified email address, Sign in with Apple prompts the user to share it with your app. The user may choose to share their real email address or an anonymous one that uses the private email relay service. In both cases, Apple verifies that the email address works and is ready for use.

Proxyアドレスが返却されても、そこと対話することはできる。

https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js/communicating_using_the_private_email_relay_service

okuokuokuoku

Google

https://developers.google.com/identity/openid-connect/openid-connect?hl=ja#obtainuserinfo

email_verified claimを提供している。 ...確かに人間向けのGoogle AccountはeMail認証なしでは発行されないけど、アカウントが人間かどうかはclaimからは判断できないんでは。。例えばGoogle WorkspaceやChromeデバイス管理 https://support.google.com/chrome/a/answer/7679958?hl=ja ではGoogleアカウントが発行されるがGMailが付帯していることは保証されない(と、思う)。