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

Hans Zandbelt hans.zandbelt at zmartzone.eu
Sun Jun 16 15:15:27 UTC 2019


How Sign in with Apple differs from OpenID Connect
https://docs.google.com/document/d/17ypy1b5TEuoLNfFWFBRZSrI1hgMNSRsKmfLApWLldXA/edit?usp=sharing
please provide input by adding comments.

Hans.

On Fri, Jun 14, 2019 at 8:42 AM Joseph Heenan via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Ah, interesting - thank you! I thought I saw something that implied the
> app had to be on the store but perhaps I misread it.
>
> Joseph
>
> On 14 Jun 2019, at 15:24, nov matake <nov at matake.jp> wrote:
>
> I have a website whose “Primary App” isn’t published at App Store.
>
> Probably this site is where Nat logged in.
> https://signin-with-apple.herokuapp.com/
>
> I assume everyone can login there.
>
> To register a client_id for Apple ID, you need to register an iOS/iPad/Mac
> ap, but you don’t have to publish it on App Store.
>
> Sent from my iPhone
>
> On Jun 14, 2019, at 15:08, Joseph Heenan via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
> It’s a subtle point - you have to have an iOS app before you can use
> signin with apple on the web. Once you have an iOS app, it works fine on
> the web (except you can’t currently access name/email via the web interface
> it seems).
>
> i.e. if you don’t have an iOS app, I believe your access to ’signin with
> apple on web’ is blocked. So, if your use is one Apple doesn’t allow on the
> App Store (porn, gambling, etc), you can’t publish an iOS app on the store,
> so you can’t use signin with apple on the web either.
>
> Joseph
>
>
> On 14 Jun 2019, at 14:48, n-sakimura <n-sakimura at nri.co.jp> wrote:
>
> 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>のメール:
>
> 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> 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> 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> 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> 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> 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
>>>> > > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>> > >
>>>>
>>>> > _______________________________________________
>>>> > Openid-specs-ab mailing list
>>>> > 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
>>>>   __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
>>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>
>>
>> --
>> hans.zandbelt at zmartzone.eu
>> ZmartZone IAM - www.zmartzone.eu
>> _______________________________________________
>> Openid-specs-ab mailing list
>> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>


-- 
hans.zandbelt at zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190616/3c21d85f/attachment-0001.html>


More information about the Openid-specs-ab mailing list