<div dir="ltr">Further issues i ran into<div><ul><li>`code id_token` response type does not respect `nonce` in the authorization request returned `id_token`</li><li>`code id_token` response type does not include `c_hash` in the authorization request returned `id_token`</li><li>providing `prompt` parameter with any value (login/consent) or empty results in a 400 with no body</li></ul><div>The interface seems to be just "connect-inspired", not connect.</div></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">S pozdravem,<br><b>Filip Skokan</b></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 4 Jun 2019 at 13:53, Mischa Salle <<a href="mailto:msalle@nikhef.nl">msalle@nikhef.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jun 04, 2019 at 12:51:10PM +0200, Filip Skokan via Openid-specs-ab wrote:<br>
> I had a look at the interface earlier today myself as well.<br>
> <br>
> The client_secret value differs from a private_key_jwt client_assertion<br>
> like so<br>
> <br>
>    1. its `sub` and `iss` are not the same client_id value<br>
>    2. it does not require `jti` (and it wouldn't probably use it for<br>
>    checking the assertion is only used once anyway)<br>
> <br>
> Apple's documentation states that the expiration of this derived client<br>
> secret JWT can be up to 6 months. My assumption is they really wanted to<br>
> stick to client secret basic/post scheme so that developers may use the<br>
> basic oauth/oidc client implementations out there but have<br>
> rotating/expiring client secrets out of the box, thats why the client<br>
> secret value is derived from a private key Apple *generates for you *(you<br>
> cannot provide your own public key).<br>
> <br>
> There's no discovery and no userinfo endpoint, id token signing is RS256<br>
> only given that the jwks_uri <<a href="https://appleid.apple.com/auth/keys" rel="noreferrer" target="_blank">https://appleid.apple.com/auth/keys</a>> only<br>
> yields a single RS256 alg key and the returned ID Token claims lack<br>
> documentation. If there's no userinfo what's the point of using code flow<br>
> and getting an access token - is it just so that clients must use the<br>
> derived secret? ¯\_(ツ)_/¯<br>
<br>
I think the hint is in<br>
<a href="https://developer.apple.com/documentation/signinwithapplerestapi/tokenresponse" rel="noreferrer" target="_blank">https://developer.apple.com/documentation/signinwithapplerestapi/tokenresponse</a><br>
    "access_token<br>
        (Reserved for future use) A token used to access allowed data.<br>
        Currently, no data set has been defined for access."<br>
<br>
Cheers,<br>
Mischa<br>
<br>
> <br>
> Apple's frontend "Sign In with Apple JS" javascript implementation is a<br>
> mystery to me as well, having a look at the JS it runs authorization within<br>
> a popup with a `code id_token` response type but `form_post` response mode<br>
> and a proprietary frame_id parameter. There's no hook for getting the<br>
> tokens back. This seems a work in progress interface.<br>
> <br>
> S pozdravem,<br>
> *Filip Skokan*<br>
> <br>
> <br>
> On Tue, 4 Jun 2019 at 12:31, Joseph Heenan via Openid-specs-ab <<br>
> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
> <br>
> > Hi all,<br>
> ><br>
> > Apple announced their own sign on solution at WWDC yesterday.<br>
> ><br>
> > It appears to be broadly OAuth2 / OpenID Connect, though this isn’t<br>
> > explicitly mentioned:<br>
> ><br>
> ><br>
> > <a href="https://developer.apple.com/documentation/signinwithapplerestapi/generate_and_validate_tokens" rel="noreferrer" target="_blank">https://developer.apple.com/documentation/signinwithapplerestapi/generate_and_validate_tokens</a><br>
> ><br>
> ><br>
> > <a href="https://developer.apple.com/documentation/signinwithapplerestapi/tokenresponse" rel="noreferrer" target="_blank">https://developer.apple.com/documentation/signinwithapplerestapi/tokenresponse</a><br>
> ><br>
> > There is an id_token in the response, but it’s contents aren’t obviously<br>
> > described beyond being ’A JSON Web Token that contains the user’s identity<br>
> > information.’<br>
> ><br>
> > One obvious oddity is that at the token endpoint you are required to pass<br>
> > a client_secret parameter that contains an ES256 JWS that is not entirely<br>
> > unlikely a client_assertion. I don’t know if that’s a mistake in the<br>
> > documentation or if Apple have deliberately moved away from a standard<br>
> > client assertion for reasons that are unclear.<br>
> ><br>
> > Is anyone at WWDC? There’s a session and a lab on Wednesday that might<br>
> > present an opportunity to ask some questions.<br>
> ><br>
> > Thanks<br>
> ><br>
> > Joseph<br>
> ><br>
> > _______________________________________________<br>
> > Openid-specs-ab mailing list<br>
> > <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> > <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
> ><br>
<br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
<br>
-- <br>
Nikhef                      Room  H155<br>
Science Park 105            Tel.  +31-20-592 5102<br>
1098 XG Amsterdam           Fax   +31-20-592 5155<br>
The Netherlands             Email <a href="mailto:msalle@nikhef.nl" target="_blank">msalle@nikhef.nl</a><br>
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..<br>
</blockquote></div>