Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Sign in with Apple

diff from OIDC / OAuth 2.0 & characteristic identifiers design

Sign in with Apple

  1. 1. #idcon vol.27 - Sign in with Apple 特集 ※ ヤフースコアのことは禁句な!! https://idcon.org
  2. 2. Sign in with Apple ~ diff from OIDC / OAuth 2.0 & characteristic identifiers design ~ @nov
  3. 3. https://matake.jp
  4. 4. https://rubygems.org/gems/apple_id
  5. 5. https://signin-with-apple.herokuapp.com
  6. 6. Diff from OIDC / OAuth 2.0
  7. 7. OIDC Spec Violations ❖ when nonce is provided in the code or code id_token grant types, it won’t be included in the id_token returned #FIXED ❖ the code id_token response type does not include c_hash in the returned id_token #FIXED ❖ the code id_token response type returns the response parameters as query parameters, not in the fragment ❖ providing a prompt parameter with any value (e.g. login or consent) or empty results in a 400 with no body #FIXED ❖ when max_age is requested, the id_token does not include an auth_time claim #FIXED http://bit.ly/diff-between-siwa-and-oidc
  8. 8. Peculiarities (奇妙な点) ❖ no Discovery document is published at https://appleid.apple.com/.well-known/openid- configuration which makes developers have to read through the Apple docs to find out about endpoints, scopes, signing algorithms, authentication methods, etc. #FEELS-OK ❖ no User Info endpoint is provided which means all of the claims about users have to be included in the (expiring and potentially large) id_token ❖ does not include different claims in the id_token based on scope #PARTIALLY-FIXED ❖ the token endpoint does not accept client_secret_basic as authentication method (required for OpenID Connect certification) and actually the default method to use for Clients when there’s no Discovery document that says otherwise http://bit.ly/diff-between-siwa-and-oidc
  9. 9. Peculiarities (奇妙な点) ❖ authentication towards the token endpoint requires a (custom) JWT assertion as a client_secret in a client_secret_post authentication method whereas the more appropriate private_key_jwt authentication method as defined in RFC7523 could have been used ❖ using unsupported or wrong parameters (e.g. non-existing response_type, scope, client_id, or redirect_uri) always results in the same message in the browser that says “Your request could not be completed because of an error. Please try again later.” without any explanation about what happened, why this is an error or how to fix it #FEELS-OK #EXCEPT-FOR-SCOPE ❖ exchanging the authorization code according to https://developer.apple.com/ documentation/signinwithapplerestapi/generate_and_validate_tokens should present a non-standard grant_type=authorization_token but using the standards-compliant grant_type=authorization_code actually works whereas the former does not, so the documentation is incorrect #FIXED http://bit.ly/diff-between-siwa-and-oidc
  10. 10. Peculiarities (奇妙な点) ❖ the Authorization Code grant type (for public Clients?) does not use PKCE to avoid code injection and code replay attacks #FEELS-OK ❖ when using the sample app available at https://github.com/aaronpk/sign-in-with- apple-example, adding openid as a scope leads to an error message and it works just with name and email as scope values; this behavior seems to be inconsistent across Clients: for some it works, or at least does not lead to errors, for others it does not work and ends with an error #FIXED? ❖ The scope value of only the very first request by an application is respected. If an application initially requests only the name scope, and the user allows it, it is then impossible to later also request the email scope. http://bit.ly/diff-between-siwa-and-oidc
  11. 11. Characteristic Identifiers Design
  12. 12. Team X
  13. 13. Team X App A
  14. 14. Team X Primary App A Service A-1
  15. 15. Team X Primary App A App A-3 App A-2 App A-1 Service A-1 Service A-2
  16. 16. Team X Primary App A App A-3 App A-2 App A-1 Service A-1 Service A-2 Primary App B App B-2 App B-1 Service B-1
  17. 17. User-related Identifiers Design
  18. 18. User ID (sub) Team X Primary App A App A-3 App A-2 App A-1 Service A-1 Service A-2 Primary App B App B-2 App B-1 Service B-1
  19. 19. Private Email Team X Primary App A App A-3 App A-2 App A-1 Service A-1 Service A-2 Primary App B App B-2 App B-1 Service B-1
  20. 20. User ID : Apple User ID : Public Emails : Private Email : 12345 000123.abc2xyz.0012 foo@icloud.com foo@me.com for-team-x@privaterelay.appleid.com Q1. Which address to use in each app’s context? Q2. How to handle email changes after revocation?
  21. 21. Consent Screen Team X Primary App A App A-3 App A-2 App A-1 Service A-1 Service A-2 Primary App B App B-2 App B-1 Service B-1
  22. 22. Revocation Screen Team X Primary App A App A-3 App A-2 App A-1 Service A-1 Service A-2 Primary App B App B-2 App B-1 Service B-1
  23. 23. Careful branding strategy required for primary app grouping
  24. 24. Developer-related Identifiers Design
  25. 25. Client ID Team X Primary App A App A-3 App A-2 App A-1 Service A-1 Service A-2 Primary App B App B-2 App B-1 Service B-1
  26. 26. Private Key Team X Primary App A App A-3 App A-2 App A-1 Service A-1 Service A-2 Primary App B App B-2 App B-1 Service B-1
  27. 27. CLIENT_ID is of the app / service which originally received the authorization code, not of the backend server which accesses the token endpoint, even when refreshing tokens.
  28. 28. Private Email Relay Service Team X Primary App A App A-3 App A-2 App A-1 Service A-1 Service A-2 Primary App B App B-2 App B-1 Service B-1
  29. 29. MAX 10 MAX 10
  30. 30. For the 11th domain / address, setup new team !?!? Primary App A sends emails from App A-1 sends emails from App A-2 sends emails from Service A-1 sends emails from no-reply@primary-app-a.example.com no-reply@app-a1.example.com no-reply@app-a2.example.com no-reply@service-a1.example.com :
  31. 31. 【結論】 iOS, iPad OS, Safari での UX は最高だが クセが強いので注意

×