Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

Brian Campbell <bcampbell@pingidentity.com> Fri, 25 April 2014 20:12 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326661A0663 for <oauth@ietfa.amsl.com>; Fri, 25 Apr 2014 13:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level:
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ov8PEBffkxpz for <oauth@ietfa.amsl.com>; Fri, 25 Apr 2014 13:12:40 -0700 (PDT)
Received: from na6sys009bog036.obsmtp.com (na6sys009bog036.obsmtp.com [74.125.150.110]) by ietfa.amsl.com (Postfix) with ESMTP id C7FF41A03D0 for <oauth@ietf.org>; Fri, 25 Apr 2014 13:12:39 -0700 (PDT)
Received: from mail-ie0-f177.google.com ([209.85.223.177]) (using TLSv1) by na6sys009bob036.postini.com ([74.125.148.12]) with SMTP ID DSNKU1rBseY1I+AagTajhqoD5oTfja0DtP/s@postini.com; Fri, 25 Apr 2014 13:12:33 PDT
Received: by mail-ie0-f177.google.com with SMTP id rl12so4133094iec.8 for <oauth@ietf.org>; Fri, 25 Apr 2014 13:12:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NJf5FhO/0N5IBbN+XvrcGSzo2cKzzU0zEcwakUYYRcs=; b=nKGkM1/7tayhOPuvS4uSSb6fstwMETD0xJ9vuA/c68qt8ONmXmXy29bsVn1DcyYQGm g95kJ6AHZaM0pyLiGZnz6IawF8HLNS0wojipsWxxjuJbHiq2jcvNDyAHYF8uy+IKFEf7 MVQdRkmhdQLw+DkklOnMumNmvpkKgeXTkoELe8Keaje/CY70qEIMIJ3BDq2R+w3Fh6WZ ABZq7yBNl3na6OI3S7h0QQp+Rd3tIYNXkcLDsGlrfMhPSqaLs0QQ1+oa2e4Gjy9QY+c9 zmVnWqBnnuPvslv28sh7o/SiA3vun424j1ugQVBfVYg0eK+WYxv0rIqGUdLv9/9ZHEVs 7KuA==
X-Gm-Message-State: ALoCoQkVNLUeqeEn1ptlYos01lriaho3cEP8oNPkiNtg7RGAMC5/RjCLowPm7OdFjsbfsKap/zkLiRiMhKPvtBfGYbWMVER1uhOxlv+oRwFJ7s8UcwLdKIt+1C0LlFfNFPi9RFOr96Zo
X-Received: by 10.50.109.230 with SMTP id hv6mr7575632igb.9.1398456753026; Fri, 25 Apr 2014 13:12:33 -0700 (PDT)
X-Received: by 10.50.109.230 with SMTP id hv6mr7575618igb.9.1398456752885; Fri, 25 Apr 2014 13:12:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.240.201 with HTTP; Fri, 25 Apr 2014 13:12:02 -0700 (PDT)
In-Reply-To: <535ABCBF.3090308@redhat.com>
References: <CA+k3eCTeBZNh8-dhtkjbCJdJ6PfciZQNQOznJj+jdik6Z6Detw@mail.gmail.com> <535ABCBF.3090308@redhat.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 25 Apr 2014 14:12:02 -0600
Message-ID: <CA+k3eCTzXS=aP8BQz2KL=0xht9wwtUEVwjgoYRjfmpy-n4HVuA@mail.gmail.com>
To: Bill Burke <bburke@redhat.com>
Content-Type: multipart/alternative; boundary=089e013a1d8efd6f6e04f7e395f5
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/suVYyhu6O5JoR7AXRppArCWarYU
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Apr 2014 20:12:42 -0000

I think it is kind of assumed, yeah. And JWT as it is gives you everything
you need for that as long as the AS and RS can agree on keys, JWE and/or
JWS, and how the claims will look. I suspect that's what most deployments
are doing with JWT access tokens today. We are, or offer JWS + JWT access
tokens as an option in product anyway, and I believe many others are doing
the same.

IHMO getting everyone to agree on the specific claims etc. needed for a
standardized JWT access token is a bit of a rat's nest, which is why
there's not been much progress in that area.






On Fri, Apr 25, 2014 at 1:51 PM, Bill Burke <bburke@redhat.com> wrote:

> Thank you.  Thats what I thought.  Is it just assumed JWT would/might be
> used an access token format for Bearer token auth?  Or is there another
> draft somewhere for that?  Is anybody out there using JWS + JWT as a access
> token format?
>
>
> On 4/25/2014 2:59 PM, Brian Campbell wrote:
>
>> draft-ietf-oauth-jwt-bearer is only about interactions (client
>> authentication and JWT as an authorization grant) with the token
>> endpoint and doesn't define JWT style access tokens.
>>
>>
>> On Fri, Apr 25, 2014 at 12:51 PM, Bill Burke <bburke@redhat.com
>> <mailto:bburke@redhat.com>> wrote:
>>
>>     Red Hat Keycloak [1] only supports basic auth for client
>>     authentication as suggested in the OAuth 2 spec.  But our access
>>     tokens are JWS signed JWTs.
>>
>>     Does draft-ietf-oauth-jwt-bearer relate to OAuth Bearer token auth
>>     [2]?  Or is there another document I should be following?  I'd like
>>     to see what other claims are being discussed related to JWT-based
>>     access tokens and may have some additional access token claims we've
>>     been experimenting with others might be interested in.
>>
>>     Also, I'm not sure yet if we'll implement
>>     draft-ietf-oauth-jwt-bearer to authenticate clients.  A lot of our
>>     initial users are more interested in public clients and/or the
>>     implicit flow as they are writing a lot of pure javascript apps
>>     served up by simple static web servers.
>>
>>     [1] http://keycloak.org
>>     [2] http://tools.ietf.org/html/__rfc6750
>>     <http://tools.ietf.org/html/rfc6750>
>>
>>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>