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

nov matake nov at matake.jp
Fri Jun 14 06:24:05 UTC 2019


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190614/93687eed/attachment-0001.html>


More information about the Openid-specs-ab mailing list