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

[Paul Madsen <[e-mail]>]

Hi Adam, FWIW I tried to tease out some of the choices & dependencies 
around OAuth for native apps in the enclosed deck


YMMV

paul

On 4/19/12 6:11 PM, Lewis Adam-CAL022 wrote:
>
> 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:[e-mail]]
> *Sent:* Thursday, April 19, 2012 5:03 PM
> *To:* Lewis Adam-CAL022; [e-mail]
> *Cc:* [e-mail]
> *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 <[e-mail]>
> To: Justin Richer <[e-mail]>
> 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:[e-mail]]
> *Sent:* Friday, April 13, 2012 11:38 AM
> *To:* Lewis Adam-CAL022
> *Cc:* [e-mail]
> *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
> [e-mail]  <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
>