Android Application Question

[Marc Boorshtein]

>
>
>
> Unless I'm totally confused, AppAuth is not something the IdP supports or
> doesn't support, it's a detail of the mobile platform to mediate the
> browser interaction to improve the user experience.
>

Just taking a quick look i think AppAuth will require OpenID Connect which
Shib doesn't support


>
> When you secure services with OAuth or cookies, you run an *SP* (in SAML
> parlance). The SP is the thing issuing the token(s) back to your
> application. It needs to authenticate the user. That's done with WebSSO and
> a browser, to interact with an IdP. The IdP is not issuing the tokens. If
> you don't want to operate a SAML SP, then you'd have a problem, but there
> are plenty of simple ways to do that if all you need to protect is a token
> issuing endpoint, the Shibboleth SP included.
>
> This whole thread is about the interactions between your app and the
> browser client. That is where all these new tricks come into play and the
> part that's rapidly evolving.
>
>
The way most if the industry is going is towards OpenID Connect for SSO
(I'm not saying its better, its just where the momentum is and big players
are pushing it like Google, MS, etc) until someone decides that JSON is too
complicated and they don't like how there's PKI involved in JWTs and it
would be SOOOO much easier to use tokens built on whatever the latest thing
is.  That being said, SAML isn't going away any time soon and I'd think a
great project for an enterprising developer would be to create an "AppAuth"
equivalent for SAML.  AppAuth is just adding libraries that makes
assumptions around how OpenID Connect works.  It'd be interesting to do the
same thing but assuming SAML.  You get that working, and now you have a set
of libraries for authenticating via any SAML2 IdP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170104/d5401669/attachment.html>