Android Application Question

[Marc Boorshtein]

>
>
>
> IdPs don't support artifact much in practice, so not really a practical
> option at this point, at least not for the Shibboleth case.
>

Thats the funny part of OIDC, its essentially the artifact profile encoded
in JSON instead of XML.  Makes sense if you think about it.  The hard part
about artifact is requiring the back-channel communications between the idp
and the sp but since most of the first OIDC idps were public (ie Google,
LinkedIn, etc) thats not a problem where as post profile is great when you
don't have that back channel pipe.


>
> But what's broken here is that it can't be the app that consumes the URL
> and requests the id_token, it has to be a web server the app is talking to.
> In which case it shouldn't matter what the URL is or what protocol is
> involved. If it's specific to OIDC, that would imply the client app is
> doing the id_token call, and that wouldn't be secure.
>

In saml there's an SP, IdP and Agent (browser).  In OIDC the RP (SP) can
ALSO be the agent.  Each device would be an RP and would use the code_token
to get an id_token (which is the assertion) which an app can validate to
know who you are (just like an assertion it's signed, has attributes,
expires, etc).   Now, most apps are going to require that  a backend web
service knows who you are.  You can send the id_token in a web service call
using OAuth2 bearer tokens (this is how Kubernetes works) OR you can use
the id_token to somehow get another token used by your web services but
once you have an id_token the IdP is done (until the id_token expires then
you use the refresh token to get a new one).



>
> So either they got this all really wrong, or more likely they just used it
> to drive an agenda without a good reason.
>
>
More like "we hate PKI and XML so we're going to invent an SSO protocol
that doesn't need them but it turns out you can't reliable establish trust
without PKI so we'll use as little as possible and jump through all sorts
of hoops that SAML solved a long time ago".  Its like when SCIM was first
created everyone in the room agreed they didn't want to create a JSON
verson of LDAP...then they created a JSON version of LDAP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170104/7ccb0cf7/attachment.html>