An seeing bad impls with justins pattern. In particular aud is not checked.
The idp has to know the rsrc aud or the as has to know the client id the mobile app is using with OP provider. It ends up being complex with room for mistakes. Phil > On Jan 26, 2017, at 10:00 AM, John Bradley <[email protected]> wrote: > > Justin and I are recommending different approaches. > > My recommendation is that your app do appAuth to your server to get a access > token for your API. Your server performs openid connect to google, SAML to > salesForce or Facebook Connect to Facebook and manages verification keys. > If the user is authenticated by the IdP it then authorizes your app on the > device to access your API. > > Justin is recommending that you build a client/relying party for each IdP > into your native app and pass the results of authentication ID_token, > Facebook signed request etc to your back end server for it to verify and > issue some cookie or webkey (probably not OAuth token) to your App for > accessing your API. > > My recommendation allowed you to protect your API using OAuth and to add or > modify IdP for your users without redeploying your native app. > > Justin's approach avoids you needing to run a OAuth authorization server. ( > He has a great open source one you could use). > > I think it is a style diffrence. I think separating authorization and > authentication into two steps is cleaner and easier to maintain over the long > term. > > John B. > >> On Jan 26, 2017 8:51 AM, "Dario Teixeira" <[email protected]> wrote: >> Hi, >> >>> https://tools.ietf.org/html/draft-ietf-oauth-native-apps [2] >>> >>> They are OpenID foundation library's not Google's. Google, Ping and >>> a number of others are active contributors if you look at the git >>> repositories. >> >> Thanks for the link. Perhaps I'm missing something, but the AppAuth >> pattern as described by this document represents only half the picture: >> at the end of the interaction, the native app is in possession of a >> token that authenticates the user. However, my server cannot accept >> that token blindly! >> >> Now, the way I would solve this is by keeping a hard-coded list of >> OpenID Provider public keys on my server, which I would use to >> verify that the token was indeed signed by the OIP. Correct me >> if I'm wrong, but this also seems to be the recommended approach, >> right? >> >> Thanks again for your time! >> Best regards, >> Dario Teixeira >>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
