Are there plans to implement any of the new OAuth 2.0 RFCs?

[dfcoffin]

Are there plans for Pivotal to implement any of the following IETF RFCs:

• RFC 7009 -- The OAuth 2.0 Token Revocation
• RFC 7521 -- Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
• RFC 7522 -- Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants
• RFC 7523 -- JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
• RFC 7591 -- OAuth 2.0 Dynamic Client Registration Protocol
• RFC 7592 -- OAuth 2.0 Dynamic Client Registration Management Protocol

I realize the IETF status of the above are "Proposed Standard" or "Experimental" but so are the following IETF standards, which are currently supported by Spring Security OAuth:

• RFC 6749 -- The OAuth 2.0 Authorization Framework
• RFC 6750 -- The OAuth 2.0 Authorization Framework: Bearer Token Usage
• RFC 7519 -- JSON Web Token (JWT)

If Pivotal does not plan to implement any of the new OAuth 2.0 RFCs, what is your recommendation for having support for the new OAuth 2.0 RFCs added to the Spring Security OAuth framework?

[william-tran]

I'm looking into RFC 7523 (and transitively 7521) as this allows for JWT tokens to be exchanged for new ones and might fit a use case I'm working on, where backend resource servers can get new tokens for contacting further backend services by using the token they receive in the request, thereby continuing to propagate the user's identity. Did you have specific use cases around the use of these new standards?

[jonekdahl]

I would also like to now if there are any plans regarding support for new OAuth2 RFCs. In particular, I would be very interested in support for RFC 7522 to allow exchange of SAML assertions for OAuth2 access tokens.

[wguttmn]

Same for me wrt. RFC 7522.

[fitzoh]

+1 for RFC 7522. It would be really nice if there was integration with Spring Security SAML.

[dfcoffin]

It's been 6 months since I first posted this issue but there has been no response from Pivotal.

Does this mean Pivotal does not have a response or is your silence indicate the life of spring-security-oauth support from Pivotal has run its full course and only user submitted solutions are available?

[dsyer]

@dfcoffin: there was a response from Will at the end of December, still a while ago, so I apologise, but nothing like as long as 6 months. We have just hired someone to look after this project, so hopefully the log jam will unjam soon.

[dfcoffin]

@dsyer Thanks for the update. @william-tran I am particularly interested in RFC 7009, RFC 7591, RFC 7592 as I have a requirement to support these in the next upgrade for openESPI (https://github.com/energyos/OpenESPI-Common-java, https://github.com/energyos/OpenESPI-DataCustodian-java, and https://github.com/energyos/OpenESPI-ThirdParty-java) which implements the governments "Green Button Initiative" based on the North American Energy Standards Board (NAESB) REQ.21 which is used by the energy industry to provide customers with energy usage in a human-readable and computer-friendly manner.

[shailendra-ksingh]

Hi,

Please somebody respond if Spring framework adheres to RFC 6749 and RFC 6750.

Thanks, Shailendra

[dsyer]

Yes, AFAIK those are not new RFCs. They are precisely the core OAuth2 spec that is implemented here. Please keep the noise down on this issue and keep it focused on new specs. If you have a question about the core specs ask it somewhere else.

[ghost]

Any hope on 7009? If I implement it on a fork, will my pull request be accepted?

[dfcoffin]

@dsyer @rwinch @william-tran Any update on the projected time frame for supporting RFC 7009, RFC 7591 and RFC 7592

[dsyer]

Work hasn't even started on 2.1.0, so there are no dates in anyone's plans, but we have some people working on this project now at least. If people were to contribute code it would be a good thing.

[tomcruise81]

@william-tran Any progress on RFC7523?

[william-tran]

This spec may take the place of RFC-7523: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07, and while there's no planned work to support either specs, I would hope that the new version of Spring Security OAuth will allow for extensibility of AccessTokenProviders like the current version.

On Wed, Apr 26, 2017 at 8:35 AM, Sean Dukehart notifications@github.com wrote:

@william-tran https://github.com/william-tran Any progress on RFC7523?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spring-projects/spring-security-oauth/issues/533#issuecomment-297450408, or mute the thread https://github.com/notifications/unsubscribe-auth/ABCMGTpfw4_ix_HyadW7Hildb0qi8vxwks5rz2Q_gaJpZM4FaCL8 .

[ghost]

MAY, but for now, RFC-7523 is used. Also what's with RFC-7009?

[exports]

So is there any WIP implementations or just plans for these oauth2.0 specs now?

[myspri]

Hello @dsyer @rwinch @william-tran, are there any examples on how to use JWT Profiles using Spring? (RFC-7523) or https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07

Any pointers in that direction will be great.

[jgrandja]

@myspri JWT Profile or Token Exchange has not been implemented within the framework.

We are also limiting new features and only providing bug fixes and minor enhancements. Our efforts are heavily focused in the new OAuth 2.0 / OpenID Connect 1.0 support coming in Spring Security 5.0.

[myspri]

Thanks @jgrandja for the quick feedback. Alternatively, is there a way to use mutual authentication to obtain access tokens? We have been using client credentials and works great, however would like to supply certificate to the token endpoint and receive a token. We are looking for solutions for not needing to supply user credentials (Basic Auth) to token endpoint in order to receive the access token.

Sorry, this may not be the right location to post this, but any guidance on this top is extremely valuable.

[jgrandja]

@myspri Spring Security supports X.509 authentication on the server-side by configuring HttpSecurity.x509(). However, there is no client-side support in the Spring Security OAuth project.

This is an important feature so I've just added the issue so it can be tracked.

[myspri]

@jgrandja, thank you so much! We have applied the x509() security but got stuck trying to bypass the basic auth. Is there any time line to this fix?
We would like to use this feature ASAP, therefore any guidance on how to solve this will be really helpful. Can you please provide some pointers?

[jgrandja]

@myspri There are quite a few other higher priority items that need to be completed first. I don't have a timeline on when this feature will be added but not for at least a couple of months. I'm not sure it will get into 5.0 as Nov is fast approaching and there is quite a bit of work left to do.

[myspri]

Okay, thanks.

[tnwang]

+1 for RFC 7522 and RFC 7523 - UAA supports these from the Authorization Server side for Cloud Foundry, and client-side support would enable app developers to begin consuming these flows.

[jgrandja]

@tnwang We will consider implementing RFC 7522 and RFC 7523 in Spring Security 5.x. Would you like log an issue in the Spring Security repo for these?

[tnwang]

Sure, opened https://github.com/spring-projects/spring-security/issues/4906

[iagotomas]

@jgrandja what about RFC7009, are there any plans/ticket to track it or it has been discarded/not yet considered?

[jgrandja]

@iagotomas Thanks for the heads up! I added spring-security/6133

[ghyoju]

any update on RFC 7522 (OAuth 2.0 SAML Bearer Assertion Flow)

[jgrandja]

@ghyoju No update as of yet. You can track the issue linked in this comment.