Hi Paul,

So by saying ‘more easily’ then there is nothing really inherently preventing a 
native implementation from making the HTTP calls to the AS directly, right?

My use cases are a bit atypical from the web service driven models that you 
guys are solving, but I think the technology should still fit.  The RS that my 
native client is talking to is *not* a web service (I realize I’m not outside 
the bounds of OAuth-proper here).  But it’s easy enough for me to use OAuth to 
get an access-token and include that in my message between my native client and 
my (non-web service) RS.  My RS can still introspect it against an OAuth STS.

These native apps I’m speaking of, I’m attempting to retrofit with OAuth, and 
today they already have native interfaces for accepting a user’s logon and 
credentials … to pop a web browser would not be intuitive to my customer base.

I don’t see any reason I can’t implement this native within my client, just 
want to be sure since the browser trick is such a prominent trend, I want to be 
sure that there’s no gotcha I haven’t thought of.

Tx!
adam

From: Paul Madsen [mailto:[email protected]]
Sent: Thursday, April 19, 2012 5:03 PM
To: Lewis Adam-CAL022; [email protected]
Cc: [email protected]
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

Using the browser as part of the AS interaction allows you to more easily 
collect the users consent.

Once you get the tokens based on that consent, everything is 'RESTful'



-------- Original message --------
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token
From: Lewis Adam-CAL022 <[email protected]>
To: Justin Richer <[email protected]>
CC: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

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 protected]]
Sent: Friday, April 13, 2012 11:38 AM
To: Lewis Adam-CAL022
Cc: [email protected]
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".

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.

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

Tx!
adam





_______________________________________________

OAuth mailing list

[email protected]<mailto:[email protected]>

https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to