Oauth2 and Codehaus

[penguinone]

I've been following the codehaus OAuth 2 implementation. It points back here for a lot of details relating to different flows.

What's the deal? What is the preferred implementation of OAuth2, and which should I be following? Is codehaus' implementation going to move forward?

Or are they identical?

Thanks!

[Keith Donald]

The Spring Security OAuth project has recently migrated under the official org.springframework.security umbrella at SpringSource. The website is now hosted at http://static.springsource.org/spring-security/oauth and the source code now resides at http://git.springsource.org/spring-security.

Ryan and his team are working on a 1.0.0 version under the new artifact id that includes full OAuth 2 and 1 support. 1.0.0.M1 was recently released to Spring's milestone repository as the following artifact:

<dependency>
	<groupId>org.springframework.security.oauth</groupId>
	<artifactId>spring-security-oauth</artifactId>
	<version>1.0.0.M1</version>
</dependency>
<repository>
    <id>org.springframework.maven.milestone</id>
    <name>Spring Maven Milestone Repository</name>
    <url>http://maven.springframework.org/milestone</url>
    <snapshots><enabled>false</enabled></snapshots>		
</repository>

I know Ryan has made every effort to preserve backwards compatibility with the Codehaus-hosted version. The one exception i know about is the new version of the library does require Spring Security 3 or greater as a base.

I'll let Ryan add more details, but hope this gets you going.

Keith

[stoicflame]

Yes, the codehaus implementation is deprecated and future development and improvements will happen here at springsource. The old documentation and libraries still exist as references, but if you're going to start a new project, start with the implementation at springsource.

[penguinone]

Cool thanks.

The Sparklr2/Tonr2 demos look like they support the web server flows only.

- Am I mistaken (I'm just getting up to speed on OAuth2)
- Does this implementation support the other flows?
- Are there demos for the other flows, particularly device flow? Or maybe planned documentation?

[stoicflame]

Just for the sake of clarity, your terminology is a bit out-of-date. The latest draft of the OAuth spec uses the term "profile" instead of "flow". Other things have also changes since the May draft. Check it out:

http://tools.ietf.org/html/draft-ietf-oauth-v2-10

The current library supports both the "web server" profile and the "device" profile. There are, indeed examples of both profiles in the tonr/sparklr application. If you take a look at the applicationContext.xml in the sparklr app, you'll see that the "my-trusted-client" client is authorized to use the "device" profile. There are unit tests in the sparklr2 application that test this out.

[raziel]

I'm just trying to deploy the tonr/sparklr sample applications and there's no mentioning of the "device" profile. Did this get removed?

[stoicflame]

In the sparklr2 applicationContext.xml:

<oauth:client clientId="my-trusted-client" authorizedGrantTypes="password,authorization_code, refresh_token"/>

The "password" grant type is specific to the device profile.

I understand this isn't obvious unless you understand the OAuth 2 spec... we need to make this clearer somehow. Any suggestions?

[raziel]

Sorry, I should have paid more attention to that.

I think the issue is that right now it's unclear from the documentation how up to date the code is with respect to the latest spec. draft - which I entirely understand.

It should get better once the spec. And code are GA, and the docs can be updated; and maybe include some more examples.

Thanks though.

[penguinone]

I agree. I have never been great at slogging through Specs personally (I'm a "find examples and get 'er done" kind of developer. Read: Don't like to read long docs). But I went through the first draft and now my mind is somewhat stuck on the original concepts.

However, I would also suggest that the connection between "password" and "device" won't necessarily be obvious, so it might be worth specifying in the configuration which profile is valid? Though if "password" is not *just* device centered as a rule, that would be too limiting. It just seems to me that when you are specifying a permission set, identifying which profile a particular user (client) is a part of makes logical sense.

Sorry, I should have paid more attention to that.

I think the issue is that right now it's unclear from the documentation how up to date the code is with respect to the latest spec. draft - which I entirely understand.

It should get better once the spec. And code are GA, and the docs can be updated; and maybe include some more examples.

Thanks though.