Hi,
And thanks for the prompt reply!
I prefer the AppAuth pattern where the native app is a OAuth client to
your server and you are protecting your API with OAuth. Your AS
becomes a Connect/SAML/Twitter auth/ Facebook etc relying party and
uses federated or local authentication to issue token
Hi,
And thanks for the prompt reply!
I would recommend making the mobile app the RP, and having the server
be an additional protected resource that accepts access tokens from
the mobile app. This is how it's commonly handled, and there are
libraries (such as Google's AppAuth) that handle most o
Hi,
I'm not sure I followed due to the use of non-standard terminology...
What do you mean by "OAuth client" - the Relying Party? And what
about AS? Is that the Authorization Server, Application Server,
or what? (One of the frustrating aspects of learning about OAuth2
and OIDC is that not ever
Hi,
+1 to AppAuth
One disturbing pattern I see for mobile apps relaying the idtoken is
that the aud isn't checked by the AS in the Oauth exchange. This in
part caused by the fact that the mobile app has two client-id
identifiers. If the aud only has the clientid for the OIDC call this
can be a
Unfortunately RFC 6749 lacks a terminology section.
>From Connect we have
>http://openid.net/specs/openid-connect-core-1_0.html#Terminology
(AS) is a common abbreviation for Authorization server.
In sec 1.1 of OAuth https://tools.ietf.org/html/rfc6749#section-1.1
Roles are defined Client and
https://tools.ietf.org/html/draft-ietf-oauth-native-apps
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.
John B.
On Jan 26, 2017 7:13 AM, "Dario Teixeira"
wrote:
> Hi,
>
> +1 to AppAuth
>>
>>
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 a
Afaik, the client app ends up with an access token (at). It never has to deal
with id tokens. That all happens by way of the oauth AS server calling oidc
itself. Iow the oauth as is the oidc client.
The code in the mobile client is trivial by comparison and does not need to do
id token valid
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 a
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 wrote:
10 matches
Mail list logo
