[Openid-specs-ab] App2app authorization/authentication

nov matake nov at matake.jp
Thu Oct 3 13:15:12 UTC 2019


My use-case isn't app2app, but it's making the mobile apps the self-issued IdP for the backend IdP.

In that case, the first logged-in app registers a public key to the backend IdP server. After that, when following app send AuthZ request to the server, the server returns another AuthZ request to the app itself. Then the app authenticate user via TouchID etc and acts as self-issued IdP against the backend. Receiving self-issued ID Token, backend IdP authenticates the user and issue code.

If the app can acts as IdP of the backend IdP, you won't need vendor-specific way to issue code.

I think George has another way in his native app SSO draft.

Sent from my iPhone

> On Oct 3, 2019, at 18:57, Joseph Heenan <joseph at authlete.com> wrote:
> 
> Hi Nov
> 
> That is a good question!
> 
> Certainly the way to do it today is very vendor specific, because my understanding is that most vendor products (at least in the versions currently deployed in the field) are very limited in the number of ways you can get them to issue an authorization code (i.e. is can be very hard to make them issue an authorization code any other way than opening the authorization endpoint in a web browser, and this scenario requires the first party app to obtain an authorization code that is then passed to the third party app). [Authlete's product is not limited in this way, and provides a lot of flexibility to issue authorization codes in appropriate ways for this scenario.]
> 
> I think it will also vary a lot depending on whether the consent screens are presented as native ui or in a browser.
> 
> Is there interest in trying to specify a vendor-neutral approach for some/all of this?
> 
> Joseph
> 
> 
> 
> 
>> On 3 Oct 2019, at 09:25, nov matake <nov at matake.jp> wrote:
>> 
>> Are you standardizing the communication between Bank’s Mobile App and AuthZ Server to obtain authorization code?
>> Or is the part using vendor specific protocol?
>> 
>> iPadから送信
>> 
>>> 2019/10/03 2:20、Joseph Heenan via Openid-specs-ab <openid-specs-ab at lists.openid.net>のメール:
>>> 
>>> Hi all,
>>> 
>>> I wrote a blog post a little while ago about app2app authorization/authentication in the OAuth2/OpenID Connect space; I think I omitted to share it here at the time and believe it could be of interest to the group.
>>> 
>>> For those that haven’t come across it, app2app is where a pre-existing mobile app (e.g. a mobile banking application) essentially claims the Authorization Endpoint using the mobile OS's deep/universal link mechanism, allowing a relying party to perform the OAuth2/openid connect dance but the user is authenticated using their normal biometric method, which massively improves the success rate as (aside from it being a lot faster/easier) a large percentage of users that regularly use biometrics have long forgotten the underlying credentials.
>>> 
>>> The post includes a video of a user granting an account aggregator app access to a bank account which may be easier to understand.
>>> 
>>> Note that this requires no changes at all to the oauth2/openid connect protocols, and it’s also fully compatible with the OIDF’s FAPI work - and is already in wide use in UK Openbanking.
>>> 
>>> The article is here:
>>> 
>>> https://josephheenan.blogspot.com/2019/08/implementing-app-to-app-authorisation.html
>>> 
>>> If I’ve missed any alternative and recommended ways to implement this I’d be very interested to hear about them.
>>> 
>>> Thanks
>>> 
>>> Joseph Heenan
>>> 
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 


More information about the Openid-specs-ab mailing list