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 < adam.le...@motorolasolutions.com> 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:jric...@mitre.org] > *Sent:* Friday, April 13, 2012 11:38 AM > *To:* Lewis Adam-CAL022 > *Cc:* oauth@ietf.org > *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**** > > OAuth@ietf.org**** > > https://www.ietf.org/mailman/listinfo/oauth**** > > ** ** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
