5:50 p.m.
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
1:22 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
4:09 a.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
8:28 a.m.
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(a)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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2523
days inactive
2524
days old
3 comments
3 participants
participants (3)
-
John D. Ament -
Marek Posolda -
Pedro Igor Silva