[Openid-specs-ab] Sign in with Apple use of non-standard OAuth2/OpenID Connect?

n-sakimura n-sakimura at nri.co.jp
Fri Jun 14 05:48:12 UTC 2019


Is that so?

AFAIK, I could successfully login with Sign in with Apple on a web application from Chrome.

Nat

2019/06/14 13:48、Joseph Heenan via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>のメール:

To me it seems pretty clear that Apple are primarily targeting iOS apps, and essentially sign in with Apple can only be used if you have an iOS app. (If you have an iOS app you can use sign in with apple on the web as well, but they clearly aren’t currently aiming to make it accessible to pure web apps that have no counterpart iOS App Store app).

I guess at least some of this will change before it comes out of beta, not being able to do an on boarding flow as easily on the web (due to the lack of user information you mention) seems like a significant omission. I’d guess they be thinking to add a userinfo style endpoint?

Joseph



On 14 Jun 2019, at 09:24, Jeff LOMBARDO via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:

Hi

At IDPro we were also mesmerized by the fact that the sub looks a lot like a JWT.

But it can de decoded like nothing of the short. Not even CWT. So I see here a kind of non trivial CRC.

As the sub looks like a JWT we hoped to retrive the user information there or thanks to it. From analisys of the native code, this is finally not the case as user information  is retrieved through other claims than sub from ASAuthorizationAppleIDCredential.

So it sounds more likely that Web/JS/pure OIDC implementation should get it from specific claims and not the sub too.

Which can be related to the scope not functioning (if you specify it it fails at consent) for the momemt when lookig at web implementation.


Jeff

Le jeu. 13 juin 2019 06:36, Hans Zandbelt via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> a écrit :
also providing the (optional) nonce in a regular code flow does not result in the (then) required inclusion in an id_token

Hans.

On Wed, Jun 12, 2019 at 12:09 PM Filip Skokan via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:
Further issues i ran into

  *   `code id_token` response type does not respect `nonce` in the authorization request returned `id_token`
  *   `code id_token` response type does not include `c_hash` in the authorization request returned `id_token`
  *   providing `prompt` parameter with any value (login/consent) or empty results in a 400 with no body

The interface seems to be just "connect-inspired", not connect.

S pozdravem,
Filip Skokan


On Tue, 4 Jun 2019 at 13:53, Mischa Salle <msalle at nikhef.nl<mailto:msalle at nikhef.nl>> wrote:
On Tue, Jun 04, 2019 at 12:51:10PM +0200, Filip Skokan via Openid-specs-ab wrote:
> I had a look at the interface earlier today myself as well.
>
> The client_secret value differs from a private_key_jwt client_assertion
> like so
>
>    1. its `sub` and `iss` are not the same client_id value
>    2. it does not require `jti` (and it wouldn't probably use it for
>    checking the assertion is only used once anyway)
>
> Apple's documentation states that the expiration of this derived client
> secret JWT can be up to 6 months. My assumption is they really wanted to
> stick to client secret basic/post scheme so that developers may use the
> basic oauth/oidc client implementations out there but have
> rotating/expiring client secrets out of the box, thats why the client
> secret value is derived from a private key Apple *generates for you *(you
> cannot provide your own public key).
>
> There's no discovery and no userinfo endpoint, id token signing is RS256
> only given that the jwks_uri <https://appleid.apple.com/auth/keys> only
> yields a single RS256 alg key and the returned ID Token claims lack
> documentation. If there's no userinfo what's the point of using code flow
> and getting an access token - is it just so that clients must use the
> derived secret? ¯\_(ツ)_/¯

I think the hint is in
https://developer.apple.com/documentation/signinwithapplerestapi/tokenresponse
    "access_token
        (Reserved for future use) A token used to access allowed data.
        Currently, no data set has been defined for access."

Cheers,
Mischa

>
> Apple's frontend "Sign In with Apple JS" javascript implementation is a
> mystery to me as well, having a look at the JS it runs authorization within
> a popup with a `code id_token` response type but `form_post` response mode
> and a proprietary frame_id parameter. There's no hook for getting the
> tokens back. This seems a work in progress interface.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Tue, 4 Jun 2019 at 12:31, Joseph Heenan via Openid-specs-ab <
> openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:
>
> > Hi all,
> >
> > Apple announced their own sign on solution at WWDC yesterday.
> >
> > It appears to be broadly OAuth2 / OpenID Connect, though this isn’t
> > explicitly mentioned:
> >
> >
> > https://developer.apple.com/documentation/signinwithapplerestapi/generate_and_validate_tokens
> >
> >
> > https://developer.apple.com/documentation/signinwithapplerestapi/tokenresponse
> >
> > There is an id_token in the response, but it’s contents aren’t obviously
> > described beyond being ’A JSON Web Token that contains the user’s identity
> > information.’
> >
> > One obvious oddity is that at the token endpoint you are required to pass
> > a client_secret parameter that contains an ES256 JWS that is not entirely
> > unlikely a client_assertion. I don’t know if that’s a mistake in the
> > documentation or if Apple have deliberately moved away from a standard
> > client assertion for reasons that are unclear.
> >
> > Is anyone at WWDC? There’s a session and a lab on Wednesday that might
> > present an opportunity to ask some questions.
> >
> > Thanks
> >
> > Joseph
> >
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
> >

> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab


--
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl<mailto:msalle at nikhef.nl>
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab


--
hans.zandbelt at zmartzone.eu<mailto:hans.zandbelt at zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu/>
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190614/a5621748/attachment-0001.html>


More information about the Openid-specs-ab mailing list