4 ms·

The gap is that Apple fully verified identity via the normal OAuth flow, and then once identiy was verified they give the use control over what email to include

The gap is that Apple fully verified identity via the normal OAuth flow, and then once identiy was verified they give the use control over what email to include in the token. The idea is that the user can include their email or an apple relay email (that forwards to their email). The bug seems to be in that step, and an attacker can provide an email that is neither their own nor an apple relay email. Your apple account is safe, but if a 3rd party trusts the signed apple payload without further verification of email, an attacker could sign in as you on the 3rd party app.

SV_BubbleTime 6y ago
That makes sense. Seems little too obvious to exist, but people make mistakes. It’s just that with JWT/JSE/JOSE already questionable security options that you would be extra super careful if you are using it. (Biggest flaw off the top of my head is it literally says what encryption is used with a NONE option meaning you can just switch to “none” and forge jwts to anyone that didn’t know not to accept those, second would be that they mix symmetric and asymmetric encryption options)
- catlifeonmars 6y ago
  I noticed after reading your comment that HS256 is marked as “required” for compliant implantations. In practice, I have only ever seen signers implement RS256 though...
  - sascha_sl 6y ago
    In OIDC you can actually specificy supported key types in the discovery process and the IdP always decides the key type anyway. HS256 relies in shared secrets, so anyone who can verify a token can also change it. RS256 allows you to download the IdP keychain every once in a while and verify tokens offline.
    - catlifeonmars 6y ago
      Yes, that’s what I meant. I only see RS256 implemented by identity providers (and advertised via .well-known/openid-configuration). This makes sense, since most identity providers are decoupled from their clients and thus cannot feasibly share a symmetric key. I am confused what is meant in the JWA specification[1] by “HS256: required” under “implementation requirements” in the table of allowed values (the entry for RS256 reads “recommended” for that column). [1]: https://tools.ietf.org/html/rfc7518#section-3.1 https://tools.ietf.org/html/rfc7518#section-3.1
dwaite 6y ago
Apple deviated from OpenID Connect, but... The third party is not supposed to link the information from an OpenID Connect client system by email address, which could change or go away at any time, and is also not guaranteed to be unique. Rather, they should use the 'sub' claim which is meant to be the same over the lifetime of the user account with the issuer.
- hirsin 6y ago
  Yup, this is it. It's a super common issue though, and we see it all the time. An app expected the email of a user to be static and keys off of it. User gets married and loses their code access. At best it's a work stoppage when someone changes their email. At worst you make assumptions about reusability of emails and give data access to the wrong account.

SV_BubbleTime 6y ago

That makes sense. Seems little too obvious to exist, but people make mistakes. It’s just that with JWT/JSE/JOSE already questionable security options that you would be extra super careful if you are using it. (Biggest flaw off the top of my head is it literally says what encryption is used with a NONE option meaning you can just switch to “none” and forge jwts to anyone that didn’t know not to accept those, second would be that they mix symmetric and asymmetric encryption options)

catlifeonmars 6y ago
I noticed after reading your comment that HS256 is marked as “required” for compliant implantations. In practice, I have only ever seen signers implement RS256 though...
- sascha_sl 6y ago
  In OIDC you can actually specificy supported key types in the discovery process and the IdP always decides the key type anyway. HS256 relies in shared secrets, so anyone who can verify a token can also change it. RS256 allows you to download the IdP keychain every once in a while and verify tokens offline.
  - catlifeonmars 6y ago
    Yes, that’s what I meant. I only see RS256 implemented by identity providers (and advertised via .well-known/openid-configuration). This makes sense, since most identity providers are decoupled from their clients and thus cannot feasibly share a symmetric key. I am confused what is meant in the JWA specification[1] by “HS256: required” under “implementation requirements” in the table of allowed values (the entry for RS256 reads “recommended” for that column). [1]: https://tools.ietf.org/html/rfc7518#section-3.1 https://tools.ietf.org/html/rfc7518#section-3.1

dwaite 6y ago

Apple deviated from OpenID Connect, but... The third party is not supposed to link the information from an OpenID Connect client system by email address, which could change or go away at any time, and is also not guaranteed to be unique. Rather, they should use the 'sub' claim which is meant to be the same over the lifetime of the user account with the issuer.

hirsin 6y ago
Yup, this is it. It's a super common issue though, and we see it all the time. An app expected the email of a user to be static and keys off of it. User gets married and loses their code access. At best it's a work stoppage when someone changes their email. At worst you make assumptions about reusability of emails and give data access to the wrong account.