JdbcTokenStore cannot be used outside Java apps.

[Paulo]

I'm working on implementing a custom jdbcTokenStore that does not rely on Java Serialization to store token information. I require this because my system needs to be able to read the database outside of Java.
For what I could gather from looking at the current JdbcTokenStore, I will need the following columns for oauth_access_token table. (when I expand the blob types):

Table: oauth_access_token

| token_id | expiration_date | token_type | refresh_token | refresh_token_expiration_date | scope |

token_id -> char(36) NOT NULL
expiration_date -> datetime NOT NULL
token_type -> char(20)
refresh_token -> char(36)
refresh_token_expiration_date -> datetime NOT NULL
scope -> char(20)

I'm discarding "additional_information" column.

Also, I see that I will need to implement oauth_refresh_token table. The complex part of oauth_refresh_token table is that, it is storing OAuth2Authentication instances, which has several components as part of its object graph:

-clientAuthentication -> scope, resourceIds, approved, authorities,
-userAuthentication -> etc
-details
-authorities
-authenticated

and so on, so it gets complicated quickly. So, I could implement this, but that is time that I could spend implementing business logic. So, is there a process to request for feature? is this something that Spring could consider implementing ? or my best chance is to implement it myself ?

Thank you !

Paulo

[Dave Syer]

You know about JIRA, right (https://jira.springsource.org/browse/SECOAUTH)? And there's a big section in the README on how to contribute to the project.

Since the access token by definition needs to be JSON serializable, I think it would be better to use that rather than native Java serialization anyway, so contributions are welcome. I don't use the JdbcTokenStore so it's not high on my list of priorities. I don't know why you would discard columns, but if you wanted to use JSON instead of native serialization you wouldn't need to because you would get all the information needed by the token services.

[Paulo]

You know about JIRA, right (https://jira.springsource.org/browse/SECOAUTH)? And there's a big section in the README on how to contribute to the project.

Since the access token by definition needs to be JSON serializable, I think it would be better to use that rather than native Java serialization anyway, so contributions are welcome. I don't use the JdbcTokenStore so it's not high on my list of priorities. I don't know why you would discard columns, but if you wanted to use JSON instead of native serialization you wouldn't need to because you would get all the information needed by the token services.

Thank you for your response. I will be happy to implement this and contribute, but right now I'm too busy with other requirements as well. I was only going to discard the additional_information because I don't have any additional information to store on my personal project, but obviously it this becomes a contribution, I wouldn't be able to discard it.
I agree that Json is better format than java serialization (at least it would be human readable), but still is not a proper way of modeling relational data, After all, a RDMS is not a document database. I will meditate a bit on this and post another message letting you know if I can get time to contribute.
Thank you,

Paulo

[Dave Syer]

Thanks for taking the time to think about it. For what it's worth, I don't believe the token data is relational, and a non-relational store would be just as good, so JSON in a CLOB would be just fine. I have a Mongo implementation that I did as a proof of concept and I don't really see much value in storing most of the data any other way.

If you might eventually work on this and/or be interested in what we do in the framework I suggest you take a minute to add a ticket to JIRA, so you can keep track of what is happening.

[LeeRead]

I'm using the JdbcTokenStore as well. I'm thankful that an implementation I can use exists, but am not crazy about serializing Java objects to binary because it makes troubleshooting and upgrades more difficult. I think converting the BLOBs to CLOBS and serializing to JSON will probably work for me. I am currently working with the M6 release. It looks like we are serializing 3 classes: OAuth2AccessToken, OAuth2Authentication and ExpiringOAuth2RefreshToken.

OAuth2AccessToken and ExpiringOAuth2RefreshToken are pretty straightforward (I'll just have the Jackson mapper ignore any current Jackson annotations in these POJOs) as they wholly belong to the Spring OAuth project.

OAuth2Authentication is a bit more interesting in that it extends from Spring Security's AbstractAuthenticationToken. Without having fully analyzed the code, I'm wondering how much of OAuth2Authentication I really need to serialize. Here's a sample json serialization of an OAuth2Authentication object:


{
"details": null,
"authorities": [],
"authenticated": false,
"userAuthentication": {
"details": null,
"authorities": [],
"authenticated": false,
"principal": "test2",
"credentials": null,
"name": "test2"
},
"credentials": "",
"principal": "test2",
"clientOnly": false,
"authorizationRequest": {
"scope": [],
"resourceIds": null,
"approved": true,
"authorities": null,
"parameters": {
"scope": null,
"redirect_uri": null,
"state": null,
"client_id": "id"
},
"state": null,
"clientId": "id",
"denied": false,
"redirectUri": null,
"responseTypes": []
},
"name": "test2"
}

-Lee-

[Dave Syer]

Yeah, the OAuth2Authentication is the thing that stopped me from doing this already. The serialization will look fine, but it will require custom deserialization in most (all?) scenarios I could think of. Maybe we need to abstract at a higher level and forgo the luxury of having the user authentication be identical with the host application - actually that makes a lot of sense if you consider that the main audience of that data is a Resource Server that probably couldn't care less about the concrete Authentication type that the Authorization Server is using. I'm thinking maybe a standard (fixed but concrete, maybe configurable for the Auth Server) Authentication might be adequate and reasonable?

[LeeRead]

Thanks for responding Dave. Given this info, I think that, for now I will opt to wipe the oauth_refresh_token and the oauth_access_token tables whenever we upgrade Spring Security or Spring Security OAuth. This will avoid any class compatibility issues.

[andolasoft]

Data persistence, the ability to maintain data between application executions, is vital to enterprise applications because the required access to relational databases. Applications that are developed for this environment must manage persistence themselves or make use of third-party solutions to handle database updates and retrievals with persistence. The Java Persistence API (JPA) provides a mechanism for managing persistence and object-relational mapping and functions for the EJB 3.0 and later specifications.

[enkhchuluun]

Yeah, the OAuth2Authentication is the thing that stopped me from doing this already. The serialization will look fine, but it will require custom deserialization in most (all?) scenarios I could think of. Maybe we need to abstract at a higher level and forgo the luxury of having the user authentication be identical with the host application - actually that makes a lot of sense if you consider that the main audience of that data is a Resource Server that probably couldn't care less about the concrete Authentication type that the Authorization Server is using. I'm thinking maybe a standard (fixed but concrete, maybe configurable for the Auth Server) Authentication might be adequate and reasonable?

I have a same scenario of LeeRead and Paulo, where relational databases is required and de/serialization is not good options even with JSON format for feature upgrade or the data exchange.

So now i see it would be the best way to create standard OAuth2Authentication (just could interface with framework) from relational data in TokenStore implemention.

maybe anyone i have a better way?

Thanks a lot.