[keycloak-user] access_token always contains JWT

[Bill Burke]

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 at smartling.com <mailto:srossillo at smartling.com>
>
>> On Feb 5, 2016, at 9:17 AM, manfred.duchrow at caprica.biz 
>> <mailto:manfred.duchrow at 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 at redhat.com>
>>> *To:* manfred.duchrow at caprica.biz
>>> *Cc:* keycloak-user <keycloak-user at 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 at 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 at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org <mailto:keycloak-user at 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 at caprica.de
>> ========================================
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org <mailto: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

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160208/970431fe/attachment-0001.html