Subject: [OAUTH-WG] Using OAuth to get a JWT/SAML token

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 12 Apr 2012 19:01:22 +0000

Hi all,

I've been talking to some of you off line about this already, but I need some help in terms of implementation.  I would like to use OAuth as a means to get either a JWT or SAML token to a client running on a handheld device.  This is something that I'm looking to prototype (as part of a larger project) beginning this week.  So, it is important to me to understand the divide between what is theoretically possible and what is actually possible.

Anybody aware of any implementations out there, either vendor or open source, that I can use for this?

Tx!
adam

---

From: Justin Richer <[email-masked]>
Date: Fri, 13 Apr 2012 12:38:24 -0400

If the mobile device has a web browser (such as a smart phone), then 
this is pretty easy, and you've got a couple of options.

One of the best options when the token is on behalf of an end user is, 
in my opinion, to use the authorization code flow like this: First, 
register what's called a "public client" with your server -- so you'll 
get an ID but not a client secret. With that client ID, register a 
custom-scheme callback URI, like "myapp://oauthcallback", and register 
your app on the device as the handler for "myapp".

In your application, to start things off, you fire off a web browser to 
the authorization server's authorization endpoint. The user logs in to 
the authorization server through the web browser, approves this copy of 
your app, and gets redirected to "myapp://oauthcallback?code=basdf132". 
Your app grabs the "myapp://" url and plucks the authorization code off 
the end of it. Your app then takes that code and sends it in the 
background to the token endpoint to exchange for a token.

Some key points:

1) You need to have access to a web browser on the platform, and it's 
considered best practice to push the user to the external browser 
application on the platform instead of embedding one. There are a couple 
paragraphs in the spec's security considerations section that talk about 
this.
2) Your app is "public" because you can't publish it with a secret at 
configuration time. It can, however, keep the tokens secret at runtime.
3) You need to be very careful with how you store the tokens on the 
device -- they need to be in a trusted space where other apps on the 
device can't sniff them out.
4) Another app can try to register "myapp://" and intercept your code on 
the way through, so make sure your codes are all one time use and short 
lived.

None of this is just theoretically possible, people are doing it today. 
What libraries and stuff you'd be after depends wholly on your platform 
(both server and client side).

  -- Justin

On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote:
>
> Hi all,
>
> I've been talking to some of you off line about this already, but I 
> need some help in terms of implementation.  I would like to use OAuth 
> as a means to get either a JWT or SAML token to a client running on a 
> handheld device.  This is something that I'm looking to prototype (as 
> part of a larger project) beginning this week.  So, it is important to 
> me to understand the divide between what is theoretically possible and 
> what is actually possible.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Fri, 13 Apr 2012 19:13:18 +0000

Hi Justin ...

In your application, to start things off, you fire off a web browser to the authorization server's authorization endpoint. The user logs in to the authorization server through the web browser, approves this copy of your app, and gets redirected to "myapp://oauthcallback?code=basdf132". Your app grabs the "myapp://" url and plucks the authorization code off the end of it. Your app then takes that code and sends it in the background to the token endpoint to exchange for a token.

<acl> this is the part I'm missing.  I understand how to get the authorization code to the client ...  I think what you're saying is that when the client present the access code to the token endpoint, that the token endpoint can return either a SAML or JWT token?  Is the token endpoint typically part of the Authorization Server?  Is the type of token returned (SAML/JWT/etc) depending on the implementation and what is supported by different vendors and open source, or is this required by the standard?  OAuth 2.0 doesn't really say a whole lot about the actual access token.  Is this all considered out of band from OAuth and a matter of implementation?  Btw ... I currently have two OAuth implementations running in the lab ... an evaluation copy of PingFederate and an open source stack (OpenAM). </acl>

---

From: John Bradley <[email-masked]>
Date: Fri, 13 Apr 2012 21:55:40 +0200

Inline.

On 2012-04-13, at 9:13 PM, Lewis Adam-CAL022 wrote:

> Hi Justin …
> <acl> this is the part I’m missing.  I understand how to get the authorization code to the client …  I think what you’re saying is that when the client present the access code to the token endpoint, that the token endpoint can return either a SAML or JWT token? 

Yes this is returned as a bearer token in OAuth speak, but the contents can be JWT or SAML.

> Is the token endpoint typically part of the Authorization Server?  Is the type of token returned (SAML/JWT/etc) depending on the implementation and what is supported by different vendors and open source, or is this required by the standard?

The Token endpoint is part of the Authorization server.

The format of the authorization and refresh tokens are not defined in the OAuth 2.0 spec, other than to treat them as opaque to the client.

>   OAuth 2.0 doesn’t really say a whole lot about the actual access token.  Is this all considered out of band from OAuth and a matter of implementation?

Yes,  some implementations send SAML tokens to the resource server, some JWT, and probably most send a proprietary or opaque token to the resource server which then calls back to a STS like service to introspect the token.

I know Justin has introspection endpoint as part of the MITRE openID connect implementation.   Ping also uses a similar one by default but can also use structured tokens.

>   Btw … I currently have two OAuth implementations running in the lab … an evaluation copy of PingFederate and an open source stack (OpenAM). </acl>

I am with one of the ForgeRock people tomorrow so I will check on what they are using for access tokens.

Both implementations will probably work for what you are trying to do.  I can't speculate on which is best for you at this point.

Regards
John B.

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 19 Apr 2012 21:37:56 +0000

Hi Justin,

There is one thing I have not understood about the whole external browser vs. embedded browser guidance ... and that is, why is *any* browser needed?  Java for example has an HTTP library, and OAuth is RESTful.  So why is it necessary to require the web browser at all, whether external or embedded?  Why can't my native client make RESTful API calls to the AS and RS natively?

Tx!
adam

From: Justin Richer [mailto:[email-masked]]
Sent: Friday, April 13, 2012 11:38 AM
To: Lewis Adam-CAL022
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

If the mobile device has a web browser (such as a smart phone), then this is pretty easy, and you've got a couple of options.

One of the best options when the token is on behalf of an end user is, in my opinion, to use the authorization code flow like this: First, register what's called a "public client" with your server -- so you'll get an ID but not a client secret. With that client ID, register a custom-scheme callback URI, like "myapp://oauthcallback", and register your app on the device as the handler for "myapp".

Some key points:

1) You need to have access to a web browser on the platform, and it's considered best practice to push the user to the external browser application on the platform instead of embedding one. There are a couple paragraphs in the spec's security considerations section that talk about this.
2) Your app is "public" because you can't publish it with a secret at configuration time. It can, however, keep the tokens secret at runtime.
3) You need to be very careful with how you store the tokens on the device -- they need to be in a trusted space where other apps on the device can't sniff them out.
4) Another app can try to register "myapp://" and intercept your code on the way through, so make sure your codes are all one time use and short lived.

None of this is just theoretically possible, people are doing it today. What libraries and stuff you'd be after depends wholly on your platform (both server and client side).

 -- Justin

Tx!
adam

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 19 Apr 2012 16:08:16 -0600

A browser isn't required. The browser based flows are pretty common with
OAuth but they are certainly not the only way to get a token.

The resource owner credentials and client credentials grant types are both
involve only direct communication between the client and the AS. And there
are also the SAML and JWT grants that allow a client to get an access token
directly from an AS without a browser being involved.

On Thu, Apr 19, 2012 at 3:37 PM, Lewis Adam-CAL022 <
[email-masked]> wrote:

>  Hi Justin,****
>
> ** **
>
> There is one thing I have not understood about the whole external browser
> vs. embedded browser guidance … and that is, why is **any** browser
> needed?  Java for example has an HTTP library, and OAuth is RESTful.  So
> why is it necessary to require the web browser at all, whether external or
> embedded?  Why can’t my native client make RESTful API calls to the AS and
> RS natively?****
>
> ** **
>
> Tx!****
>
> adam****
>
> ** **
>
> *From:* Justin Richer [mailto:[email-masked]]
> *Sent:* Friday, April 13, 2012 11:38 AM
> *To:* Lewis Adam-CAL022
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token****
>
> ** **
>
> If the mobile device has a web browser (such as a smart phone), then this
> is pretty easy, and you've got a couple of options.
>
> One of the best options when the token is on behalf of an end user is, in
> my opinion, to use the authorization code flow like this: First, register
> what's called a "public client" with your server -- so you'll get an ID but
> not a client secret. With that client ID, register a custom-scheme callback
> URI, like "myapp://oauthcallback", and register your app on the device as
> the handler for "myapp".
>
> the authorization server's authorization endpoint. The user logs in to the
> authorization server through the web browser, approves this copy of your
> app, and gets redirected to "myapp://oauthcallback?code=basdf132". Your app
> grabs the "myapp://" url and plucks the authorization code off the end of
> it. Your app then takes that code and sends it in the background to the
> token endpoint to exchange for a token.
>
> Some key points:
>
> 3) You need to be very careful with how you store the tokens on the device
> -- they need to be in a trusted space where other apps on the device can't
> sniff them out.
> On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote: ****
>
> Hi all,****
>
>  ****
>
> I’ve been talking to some of you off line about this already, but I need
> some help in terms of implementation.  I would like to use OAuth as a means
> to get either a JWT or SAML token to a client running on a handheld
> device.  This is something that I’m looking to prototype (as part of a
> larger project) beginning this week.  So, it is important to me to
> understand the divide between what is theoretically possible and what is
> actually possible.****
>
>  ****
>
> Anybody aware of any implementations out there, either vendor or open
> source, that I can use for this?****
>
>  ****
>
> Tx!
> adam****
>
>
>
>
> ****
>
> _______________________________________________****
>
> OAuth mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 19 Apr 2012 22:25:34 +0000

Hi Brian,

I was also looking at the resource owner credentials flow, but it seems limited to username & password ... it's not clear that it would work with stronger authentication methods such as RSA.  Thoughts?

adam

From: Brian Campbell [mailto:[email-masked]]
Sent: Thursday, April 19, 2012 5:08 PM
To: Lewis Adam-CAL022
Cc: Justin Richer; [email-masked]
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

A browser isn't required. The browser based flows are pretty common with OAuth but they are certainly not the only way to get a token.

The resource owner credentials and client credentials grant types are both involve only direct communication between the client and the AS. And there are also the SAML and JWT grants that allow a client to get an access token directly from an AS without a browser being involved.
On Thu, Apr 19, 2012 at 3:37 PM, Lewis Adam-CAL022 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Justin,

Tx!
adam

From: Justin Richer [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, April 13, 2012 11:38 AM
To: Lewis Adam-CAL022
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

Some key points:

 -- Justin

Tx!
adam

OAuth mailing list

---

From: Brian Campbell <[email-masked]>
Date: Fri, 20 Apr 2012 06:26:54 -0600

You're right, resource owner credentials is specifically for username and
password. If by RSA you mean a one time password from a hard token, you
might be able to kind of shove it into a resource owner credentials flow.
But I don't think that was really the intent. If you mean RSA signatures,
then it doesn't really work.

In general stronger forms of user authentication for direct client to AS
communications are allowed for by the extensibility of the grant type
mechanism: http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.5but
that does require an extension spec or a proprietary implementation.

There is work underway to standardize some assertion/token grants with this
abstract definition
http://tools.ietf.org/html/draft-ietf-oauth-assertionsand these more
concrete definitions for SAML and JWT respectively
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer and
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer

Neither of those directly address the question of other forms of stronger
authentication directly with the AS. However some from of stronger authn
could have been used to acquire the SAML or JWT - maybe an X509 token sent
to an STS. Admittedly that just kind of pushes the problem around and
there's some chicken and egg going on here.

On Thu, Apr 19, 2012 at 4:25 PM, Lewis Adam-CAL022 <
[email-masked]> wrote:

>  Hi Brian,****
>
> ** **
>
> I was also looking at the resource owner credentials flow, but it seems
> limited to username & password … it’s not clear that it would work with
> stronger authentication methods such as RSA.  Thoughts?****
>
> ** **
>
> adam****
>
> ** **
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Thursday, April 19, 2012 5:08 PM
> *To:* Lewis Adam-CAL022
> *Cc:* Justin Richer; [email-masked]
>
> directly from an AS without a browser being involved.****
>
> [email-masked]> wrote:****
>
> Hi Justin,****
>
>  ****
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 20 Apr 2012 10:33:44 -0400

It's a difference between the front channel and the back channel. See 
attached diagram for a very high level overview that I've used in a few 
talks.

The browser is for flows where you need the user and their 
authentication present in order to make the connection, such as the 
authz code or implicit flows. The idea is that you, as the client, fire 
off a web browser to send the user over to the authorization endpoint 
directly, where they authenticate with the authorization server using 
whatever mechanism they can. This lets you use two factor, certificates, 
openid, username/password, whatever. The client doesn't have to support 
or see any of this because it's all happening in a browser between the 
user and the authorization server, which probably already has a direct 
user log in mechanism it has access to.

As has been pointed out, you can do OAuth2 without involving the front 
channel at all by using the client credentials, resource owner 
credentials, or assertion flows. None of these sound like they fit what 
you want to do, though. And it's trivial to pop open a browser in most 
platforms; the trick has historically been getting the callback from the 
site, which is less of a problem on mobile platforms.

Side note, OAuth is not really RESTful, but its tokens are easily 
compatible with RESTful APIs.

  -- Justin

On 04/19/2012 05:37 PM, Lewis Adam-CAL022 wrote:
>
> Hi Justin,
>
> There is one thing I have not understood about the whole external 
> browser vs. embedded browser guidance ... and that is, why is **any** 
> browser needed?  Java for example has an HTTP library, and OAuth is 
> RESTful.  So why is it necessary to require the web browser at all, 
> whether external or embedded?  Why can't my native client make RESTful 
> API calls to the AS and RS natively?
>
> Tx!
>
> adam
>
> *From:*Justin Richer [mailto:[email-masked]]
> *Subject:* Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token
>
> In your application, to start things off, you fire off a web browser 
> to the authorization server's authorization endpoint. The user logs in 
> to the authorization server through the web browser, approves this 
> copy of your app, and gets redirected to 
> "myapp://oauthcallback?code=basdf132". Your app grabs the "myapp://" 
> url and plucks the authorization code off the end of it. Your app then 
> takes that code and sends it in the background to the token endpoint 
> to exchange for a token.
>
> Some key points:
>
> application on the platform instead of embedding one. There are a 
> couple paragraphs in the spec's security considerations section that 
> talk about this.
> 4) Another app can try to register "myapp://" and intercept your code 
> on the way through, so make sure your codes are all one time use and 
> short lived.
>
> None of this is just theoretically possible, people are doing it 
> today. What libraries and stuff you'd be after depends wholly on your 
> platform (both server and client side).
>
>  -- Justin
>
> source, that I can use for this?
>
> Tx!
> adam
>
>
>
>
> [email-masked]  <mailto:[email-masked]>