[keycloak-user] IDToken vs AccessToken

[Pedro Igor Silva]

The ID Token is related with OpenID Connect. And this standard is basically
about enabling authentication on top of OAuth2. The ID Token represents an
identity and what parties need to know about it in order to establish a
security context. It tells you who you are but not what you can do.

In the other hand, ATs are more related with the permissions you were
granted in order to access resources protected by a resource server. Where
ATs are usually related with a client acting on behalf of an end user (or
resource owner). ATs hold the scopes granted by the server (usually as a
result of user consent) which can be used by resource servers to decide
whether or not a client is allowed to access some protected resource.

Like Marek said, ATs are the right choice for accessing resources in your
backend.

Regards.
Pedro Igor


On Tue, Jun 13, 2017 at 6:09 AM, John D. Ament <john.d.ament at gmail.com>
wrote:

> Marek,
>
> So If I had to digest what you're saying, it sounds like I want my backend
> to rely on the AccessToken object more than the IDToken object.
>
> Sound right?
>
> John
>
> On Tue, Jun 13, 2017 at 2:22 AM Marek Posolda <mposolda at redhat.com> wrote:
>
> > The secured applications can be divided into 2 main groups:
> > - Frontend applications: Those are servlet or javascript UI
> > applications, which want to authenticate against Keycloak and they use
> > full browser based OIDC flow for it. Once OIDC flow is finished,
> > application will receive all 3 tokens:  access token, idToken and
> > refresh token.
> > - Bearer-only (usually REST based) applications: Those are secured by
> > the bearer token (access token) sent to them in the "Authorization:
> > Bearer" header. Usually some frontend application authenticated
> > previously with Keycloak send the access token to the REST based
> > application to authenticate particular REST request. Note that bearer
> > applications don't set any cookie, they don't have any session, they
> > don't redirect to OIDC and they don't use any other tokens beside the
> > access token sent to them in the header.
> >
> > See our docs and demo example for more details. The applications like
> > "customer-portal" and "product-portal" are frontend applications when
> > the "database-service" is the REST based application.
> >
> > Marek
> >
> >
> > On 13/06/17 00:50, John D. Ament wrote:
> > > Hi
> > >
> > > I noticed that when using Bearer, an AccessToken gets set in the
> > > KeycloakPrincipal's SecurityContext.  However, when I do an SP
> initiated
> > > login the IDToken gets set.  I was wondering if these two could be
> > > consistent, or if the inconsistency were at least explainable?
> > >
> > > I'm also wondering, will the presence of a bearer header cause the
> > keycloak
> > > adapter cookie to get set?
> > >
> > > John
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
> >
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>