[OpenID] Native App and web API: Is this the proper use of OpenID Connect for this use case?

[Peter Williams]

What I find fascinating, just recently, is this ideas that one as is now supported by multiple idps (and that openid connect specifically multiplexes them.).

There is therefore no particularly tight coupling between webapp and idp (minting id token).

In the windows cloud world, you see that obviously these days. At a common /auth and /token endpoint (in 1 admd) you can get id tokens now from either a billion liveid/hotmail/consumer accounts (1mega idp, that is), or 1,000,000+ enterprise idps (on premise or cloud services, or dome mix) each with 10-10k users typically, in some prmd namespace (or its synonym).

I firmly believe it wont be long before one adds a million more idps (each one google apps idp) along with another mega idp or two (Gmail, and facebook)...

See I'm not at at all anti American, lauding the us national identity initiative which formented this (as did market pressure to have families of non google-identity -managed apps, on a google phone.. ). Good stuff, when transparent, and without secret layers.

A separate issue is sp centric name decoupling, and session tokens, features I see in some stacks and not others.

Sent from my Windows Phone
________________________________
From: Brian Campbell<mailto:bcampbell at pingidentity.com>
Sent: ‎5/‎26/‎2015 6:11 AM
To: Andy Brown<mailto:Andrew_Brown at rhoworld.com>
Cc: openid-general at lists.openid.net<mailto:openid-general at lists.openid.net>
Subject: Re: [OpenID] Native App and web API: Is this the proper use of OpenID Connect for this use case?

I think it sort of depends on how closely related your components are (or
you want them to be). In what you described, the RS / SP API needs to be
able to validate the AS / IDP's access token, which sort of implies a close
relationship between the SP and IDP given the nature of most OAuth
deployments. This likely creates a pretty tight coupling from the API to
that particular IDP. If they are both in the same administrative domain,
that probably works. But could be problematic, if not.

More generally I think it makes sense for a service provide to issue its
own access tokens for its own APIs. And use Connect (or whatever web SSO
protocol) for user authentication. That decouples the APIs tokens from the
IDP and allows different IDPs to be used.

I tried to describe (with pictures!) this model in a talk I did last week -
the flow starts here:
http://www.slideshare.net/briandavidcampbell/gluecon2015-mobile-sso/47


On Wed, May 20, 2015 at 8:27 AM, Andy Brown <Andrew_Brown at rhoworld.com>
wrote:

> I'm trying to understand how to use OpenId Connect in the following use
> case. Let's say we just have the following 3 components:
>
> * Web app with an exposed API (Service Provider aka SP).
> * A separate authentication server (Identify Provider aka IDP) used for
> SSO with the above SP.
> * A native client app used by the End User. This client app uses the SP's
> API.
>
> All traffic would be over HTTPS. Here's how I envision the OpenID Connect
> process working:
>
> 1. The native app would request a "token" from the SP.
> 2. The SP would see the user isn't authenticated and ask for verification
> from the trusted IDP.
> 3. After the user's credentials are provided to the IDP, the IDP would
> return an ID token and Access token to the SP.
> 4. The SP would verify the ID token and give the Access token to the
> native client app to use for all subsequent requests to the API.
>
> Is this the recommended way to use OpenID Connect in this situation? Any
> obvious security concerns? The only one I see is that the native client app
> could use the Access token to access the User Info endpoint at the IDP.
>
> Thanks for any help!
>
> - Andy
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20150526/27041aaf/attachment.html>
-------------- next part --------------
_______________________________________________
general mailing list
general at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general