4:17 a.m.
Hi,
I am trying to retrieve an access token from a Keycloak (1.8.0.Final)
service account by
POST /auth/realms/myrealm/protocol/openid-connect/token
with grant_type=client_credentials.
The result contains a signed JWT as value of field "access_token" rather
than a simple token
as described in chapter 18 (Service Accounts) of the user guide.
So what I expect (need) is a response like this:
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"bearer",
"expires_in":60,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"refresh_expires_in":600,
"id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"not-before-policy":0,
"session-state":"234234-234234-234234"
}
Is there a way to configure the account or the realm to return a simple
token
in "access_token" (and "refresh_token") rather than a JWT?
Cheers,
Manfred
6:10 a.m.
There's no such thing as a "simple token". Tokens are always a signed JWT.
On 5 February 2016 at 11:17, <manfred.duchrow(a)caprica.biz> wrote:
Hi,
I am trying to retrieve an access token from a Keycloak (1.8.0.Final)
service account by
POST /auth/realms/myrealm/protocol/openid-connect/token
with grant_type=client_credentials.
The result contains a signed JWT as value of field "access_token" rather
than a simple token
as described in chapter 18 (Service Accounts) of the user guide.
So what I expect (need) is a response like this:
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"bearer",
"expires_in":60,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"refresh_expires_in":600,
"id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"not-before-policy":0,
"session-state":"234234-234234-234234"
}
Is there a way to configure the account or the realm to return a simple
token
in "access_token" (and "refresh_token") rather than a JWT?
Cheers,
Manfred
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
6:47 a.m.
Access token is implementation specific. Some commercial software have the concept of
"reference tokens" which are nothing but random strings indicated below. The
clients have to query back the Authorization server to get a validated JWT token
From: Stian Thorgersen <sthorger(a)redhat.com>
To: manfred.duchrow(a)caprica.biz
Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
Sent: Friday, February 5, 2016 7:10 AM
Subject: Re: [keycloak-user] access_token always contains JWT
There's no such thing as a "simple token". Tokens are always a signed JWT.
On 5 February 2016 at 11:17, <manfred.duchrow(a)caprica.biz> wrote:
Hi,
I am trying to retrieve an access token from a Keycloak (1.8.0.Final)
service account by
POST /auth/realms/myrealm/protocol/openid-connect/token
with grant_type=client_credentials.
The result contains a signed JWT as value of field "access_token" rather
than a simple token
as described in chapter 18 (Service Accounts) of the user guide.
So what I expect (need) is a response like this:
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"bearer",
"expires_in":60,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"refresh_expires_in":600,
"id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"not-before-policy":0,
"session-state":"234234-234234-234234"
}
Is there a way to configure the account or the realm to return a simple
token
in "access_token" (and "refresh_token") rather than a JWT?
Cheers,
Manfred
_______________________________________________
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
8:17 a.m.
Yes, that's true (even for some open source software too).
So am I supposed to put this JWT access token into the Authorization
request header as Bearer value to authorize a request?
The access token I got from Keycloak is over 5000 characters long!
On 05.02.2016 13:47, Raghuram Prabhala wrote:
Access token is implementation specific. Some commercial software
have
the concept of "reference tokens" which are nothing but random strings
indicated below. The clients have to query back the Authorization
server to get a validated JWT token
------------------------------------------------------------------------
*From:* Stian Thorgersen <sthorger(a)redhat.com>
*To:* manfred.duchrow(a)caprica.biz
*Cc:* keycloak-user <keycloak-user(a)lists.jboss.org>
*Sent:* Friday, February 5, 2016 7:10 AM
*Subject:* Re: [keycloak-user] access_token always contains JWT
There's no such thing as a "simple token". Tokens are always a signed JWT.
On 5 February 2016 at 11:17, <manfred.duchrow(a)caprica.biz
<mailto:manfred.duchrow@caprica.biz>> wrote:
Hi,
I am trying to retrieve an access token from a Keycloak (1.8.0.Final)
service account by
POST /auth/realms/myrealm/protocol/openid-connect/token
with grant_type=client_credentials.
The result contains a signed JWT as value of field "access_token" rather
than a simple token
as described in chapter 18 (Service Accounts) of the user guide.
So what I expect (need) is a response like this:
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"bearer",
"expires_in":60,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"refresh_expires_in":600,
"id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"not-before-policy":0,
"session-state":"234234-234234-234234"
}
Is there a way to configure the account or the realm to return a simple
token
in "access_token" (and "refresh_token") rather than a JWT?
Cheers,
Manfred
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
========================================
Caprica Ltd.
69 Great Hampton Street
Birmingham, West Midlands, B186EW,
Registered in England and Wales
Company No. 5298548
Managing Director: Manfred Duchrow
Zweigniederlassung Deutschland
Gartenstr. 48, 89150 Laichingen
Amtsgericht Ulm: HRB 5073
Geschäftsführer: Manfred Duchrow
----------------------------------------
Tel: +49 (0)7333 9232190
Fax: +49 (0)7333 9232191
E-Mail: manfred.duchrow(a)caprica.de
========================================
11:16 a.m.
Opaque access tokens are an interesting idea for security reasons. I’ve heard them
referred to as "by reference" access tokens because the actual JWT access token
has to be stored somewhere. The OpenID spec doesn’t address this but it’s a solid idea for
access tokens exposed to external applications, which do not need to be concerned with, or
possibly shouldn’t be privy to the information inside the token.
There’s another option that may be more manageable. That is to offer a per client option
of encrypting the access token, known as JWE, or JSON Web Encryption[0]. The basic idea is
that the signed token is then encrypted with a symmetrical key. This key would probably be
a realm level key. Another benefit or JWE is the access token payload is compressed,
making the access token shorter.
Is this something we would be interested in adding support for?
[0]: https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com
On Feb 5, 2016, at 9:17 AM, manfred.duchrow(a)caprica.biz wrote:
Yes, that's true (even for some open source software too).
So am I supposed to put this JWT access token into the Authorization request header as
Bearer value to authorize a request?
The access token I got from Keycloak is over 5000 characters long!
On 05.02.2016 13:47, Raghuram Prabhala wrote:
> Access token is implementation specific. Some commercial software have the concept of
"reference tokens" which are nothing but random strings indicated below. The
clients have to query back the Authorization server to get a validated JWT token
>
>
>
> From: Stian Thorgersen <sthorger(a)redhat.com>
<mailto:sthorger@redhat.com>
> To: manfred.duchrow(a)caprica.biz <mailto:manfred.duchrow@caprica.biz>
> Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
<mailto:keycloak-user@lists.jboss.org>
> Sent: Friday, February 5, 2016 7:10 AM
> Subject: Re: [keycloak-user] access_token always contains JWT
>
> There's no such thing as a "simple token". Tokens are always a signed
JWT.
>
> On 5 February 2016 at 11:17, <
<mailto:manfred.duchrow@caprica.biz>manfred.duchrow@caprica.biz
<mailto:manfred.duchrow@caprica.biz>> wrote:
> Hi,
>
> I am trying to retrieve an access token from a Keycloak (1.8.0.Final)
> service account by
> POST /auth/realms/myrealm/protocol/openid-connect/token
> with grant_type=client_credentials.
>
> The result contains a signed JWT as value of field "access_token" rather
> than a simple token
> as described in chapter 18 (Service Accounts) of the user guide.
>
> So what I expect (need) is a response like this:
>
> {
> "access_token":"2YotnFZFEjr1zCsicMWpAA",
> "token_type":"bearer",
> "expires_in":60,
> "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
> "refresh_expires_in":600,
> "id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
> "not-before-policy":0,
> "session-state":"234234-234234-234234"
> }
>
> Is there a way to configure the account or the realm to return a simple
> token
> in "access_token" (and "refresh_token") rather than a JWT?
>
> Cheers,
> Manfred
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
<https://lists.jboss.org/mailman/listinfo/keycloak-user>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
<https://lists.jboss.org/mailman/listinfo/keycloak-user>
>
--
========================================
Caprica Ltd.
69 Great Hampton Street
Birmingham, West Midlands, B186EW,
Registered in England and Wales
Company No. 5298548
Managing Director: Manfred Duchrow
Zweigniederlassung Deutschland
Gartenstr. 48, 89150 Laichingen
Amtsgericht Ulm: HRB 5073
Geschäftsführer: Manfred Duchrow
----------------------------------------
Tel: +49 (0)7333 9232190
Fax: +49 (0)7333 9232191
E-Mail: manfred.duchrow(a)caprica.de <mailto:manfred.duchrow@caprica.de>
========================================
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
11:22 a.m.
Yes. We want that. Just too busy :)
On 2/8/2016 12:16 PM, Scott Rossillo wrote:
Opaque access tokens are an interesting idea for security reasons.
I’ve heard them referred to as "by reference" access tokens because
the actual JWT access token has to be stored somewhere. The OpenID
spec doesn’t address this but it’s a solid idea for access tokens
exposed to external applications, which do not need to be concerned
with, or possibly shouldn’t be privy to the information inside the token.
There’s another option that may be more manageable. That is to offer a
per client option of encrypting the access token, known as JWE, or
JSON Web Encryption[0]. The basic idea is that the signed token is
then encrypted with a symmetrical key. This key would probably be a
realm level key. Another benefit or JWE is the access token payload is
compressed, making the access token shorter.
Is this something we would be interested in adding support for?
[0]: https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com <mailto:srossillo@smartling.com>
> On Feb 5, 2016, at 9:17 AM, manfred.duchrow(a)caprica.biz
> <mailto:manfred.duchrow@caprica.biz> wrote:
>
> Yes, that's true (even for some open source software too).
> So am I supposed to put this JWT access token into the Authorization
> request header as Bearer value to authorize a request?
> The access token I got from Keycloak is over 5000 characters long!
>
>
> On 05.02.2016 13:47, Raghuram Prabhala wrote:
>> Access token is implementation specific. Some commercial software
>> have the concept of "reference tokens" which are nothing but random
>> strings indicated below. The clients have to query back the
>> Authorization server to get a validated JWT token
>>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Stian Thorgersen <sthorger(a)redhat.com>
>> *To:* manfred.duchrow(a)caprica.biz
>> *Cc:* keycloak-user <keycloak-user(a)lists.jboss.org>
>> *Sent:* Friday, February 5, 2016 7:10 AM
>> *Subject:* Re: [keycloak-user] access_token always contains JWT
>>
>> There's no such thing as a "simple token". Tokens are always a
>> signed JWT.
>>
>> On 5 February 2016 at 11:17, <manfred.duchrow(a)caprica.biz> wrote:
>>
>> Hi,
>>
>> I am trying to retrieve an access token from a Keycloak (1.8.0.Final)
>> service account by
>> POST /auth/realms/myrealm/protocol/openid-connect/token
>> with grant_type=client_credentials.
>>
>> The result contains a signed JWT as value of field "access_token"
rather
>> than a simple token
>> as described in chapter 18 (Service Accounts) of the user guide.
>>
>> So what I expect (need) is a response like this:
>>
>> {
>> "access_token":"2YotnFZFEjr1zCsicMWpAA",
>> "token_type":"bearer",
>> "expires_in":60,
>> "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
>> "refresh_expires_in":600,
>> "id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
>> "not-before-policy":0,
>> "session-state":"234234-234234-234234"
>> }
>>
>> Is there a way to configure the account or the realm to return a simple
>> token
>> in "access_token" (and "refresh_token") rather than a
JWT?
>>
>> Cheers,
>> Manfred
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>
> --
> ========================================
> Caprica Ltd.
> 69 Great Hampton Street
> Birmingham, West Midlands, B186EW,
> Registered in England and Wales
> Company No. 5298548
> Managing Director: Manfred Duchrow
>
> Zweigniederlassung Deutschland
> Gartenstr. 48, 89150 Laichingen
> Amtsgericht Ulm: HRB 5073
> Geschäftsführer: Manfred Duchrow
> ----------------------------------------
> Tel: +49 (0)7333 9232190
> Fax: +49 (0)7333 9232191
> E-Mail:manfred.duchrow@caprica.de
> ========================================
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
1:22 p.m.
+1 on this, but I understand the time constraints.
From:
<keycloak-user-bounces@lists.jboss.org<mailto:keycloak-user-bounces@lists.jboss.org>>
on behalf of Bill Burke <bburke@redhat.com<mailto:bburke@redhat.com>>
Date: Monday, February 8, 2016 at 12:22 PM
To: "keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>"
<keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>>
Subject: Re: [keycloak-user] access_token always contains JWT
Yes. We want that. Just too busy :)
On 2/8/2016 12:16 PM, Scott Rossillo wrote:
Opaque access tokens are an interesting idea for security reasons. I've heard them
referred to as "by reference" access tokens because the actual JWT access token
has to be stored somewhere. The OpenID spec doesn't address this but it's a solid
idea for access tokens exposed to external applications, which do not need to be concerned
with, or possibly shouldn't be privy to the information inside the token.
There's another option that may be more manageable. That is to offer a per client
option of encrypting the access token, known as JWE, or JSON Web Encryption[0]. The basic
idea is that the signed token is then encrypted with a symmetrical key. This key would
probably be a realm level key. Another benefit or JWE is the access token payload is
compressed, making the access token shorter.
Is this something we would be interested in adding support for?
[0]: https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40
Scott Rossillo
Smartling | Senior Software Engineer
srossillo@smartling.com<mailto:srossillo@smartling.com>
On Feb 5, 2016, at 9:17 AM, <mailto:manfred.duchrow@caprica.biz>
manfred.duchrow@caprica.biz<mailto:manfred.duchrow@caprica.biz> wrote:
Yes, that's true (even for some open source software too).
So am I supposed to put this JWT access token into the Authorization request header as
Bearer value to authorize a request?
The access token I got from Keycloak is over 5000 characters long!
On 05.02.2016 13:47, Raghuram Prabhala wrote:
Access token is implementation specific. Some commercial software have the concept of
"reference tokens" which are nothing but random strings indicated below. The
clients have to query back the Authorization server to get a validated JWT token
________________________________
From: Stian Thorgersen <sthorger@redhat.com><mailto:sthorger@redhat.com>
To: <mailto:manfred.duchrow@caprica.biz>
manfred.duchrow@caprica.biz<mailto:manfred.duchrow@caprica.biz>
Cc: keycloak-user <mailto:keycloak-user@lists.jboss.org>
<keycloak-user@lists.jboss.org><mailto:keycloak-user@lists.jboss.org>
Sent: Friday, February 5, 2016 7:10 AM
Subject: Re: [keycloak-user] access_token always contains JWT
There's no such thing as a "simple token". Tokens are always a signed JWT.
On 5 February 2016 at 11:17,
<<mailto:manfred.duchrow@caprica.biz>manfred.duchrow@caprica.biz<mailto:manfred.duchrow@caprica.biz>>
wrote:
Hi,
I am trying to retrieve an access token from a Keycloak (1.8.0.Final)
service account by
POST /auth/realms/myrealm/protocol/openid-connect/token
with grant_type=client_credentials.
The result contains a signed JWT as value of field "access_token" rather
than a simple token
as described in chapter 18 (Service Accounts) of the user guide.
So what I expect (need) is a response like this:
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"bearer",
"expires_in":60,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"refresh_expires_in":600,
"id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"not-before-policy":0,
"session-state":"234234-234234-234234"
}
Is there a way to configure the account or the realm to return a simple
token
in "access_token" (and "refresh_token") rather than a JWT?
Cheers,
Manfred
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
========================================
Caprica Ltd.
69 Great Hampton Street
Birmingham, West Midlands, B186EW,
Registered in England and Wales
Company No. 5298548
Managing Director: Manfred Duchrow
Zweigniederlassung Deutschland
Gartenstr. 48, 89150 Laichingen
Amtsgericht Ulm: HRB 5073
Geschäftsführer: Manfred Duchrow
----------------------------------------
Tel: +49 (0)7333 9232190
Fax: +49 (0)7333 9232191
E-Mail: manfred.duchrow@caprica.de<mailto:manfred.duchrow@caprica.de>
========================================
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3230
days inactive
3233
days old
6 comments
6 participants
participants (6)
-
Bill Burke -
manfred.duchrow＠caprica.biz -
Paul Blair -
Raghuram Prabhala -
Scott Rossillo -
Stian Thorgersen