On 7/23/2014 11:13 AM, Stian Thorgersen wrote:
I've completed all the pre-work required before storing
AccessCode details in UserSessionProvider.
What's be done to AccessCode is:
* It no longer contains AccessToken. Instead it just contains the list of requested roles
(intersection of client scope and user roles). The AccessToken is generated from this in
the TokenService.codeToToken
* authMethod, usernameUsed and rememberMe has been moved to UserSessionModel
* list of RequiredActions have been changed to a single action. The action can be one of
the required actions, oauth_grant, or nothing. A code can only be used for the action
currently set on it. For example if the code is set to VERIFY_EMAIL that is the only thing
it's useful for. Also added the oauth_grant action to make sure a user has verified
the grants (if client obviously) before the code is active and can be used to obtain a
token.
* expiration has been removed. Instead the timestamp and
realm.getAccessCodeLifespan/getAccessCodeLifespanUserAction is used directly.
That's it. Next step is to the details in UserSessionProvider and only send the id as
the code query param.
Question: is sending UUID + timestamp sufficient as the code, or should we sign it with
JWSBuilder as well?
Don't think you need a timestamp as the user session should have a
timestamp. Without signature, isn't this another brute force vulnerability?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com