Realm associated with OAuth2 tokens is not normalised

This may also occur during other methods of OAuth2 token creation, but for the purposes here I've only tested using password grant and the initial refresh and access tokens created at this point.

curl --request POST --user "oauth2client:password" --data "grant_type=password&username=demo&password=changeit"  "http://openam.example.com:8080/openam/oauth2/access_token?realm=/test/"

When making the initial request you can pass in the realm with or without extra slashes and it will still normalise and find the right realm and OAuth2Provider. e.g. /test, test and /test/ all result in successful login/access_token.

However, when the tokens are created/saved, the original 'passed in' realm value is stored, e.g:

    coreTokenString08 = test
    coreTokenString08 = /test/
    coreTokenString08 = /test

If this value is ever read back out and compared against the realm again, results may be inconsistent.

An example within OpenAM of where this doesn't work is when a user requests their tokens via /frrest/oauth2/token/?_queryId=access_token

OpenAM uses the version of the realm from the users session which in this case is '/test' and uses it in the LDAP search:

[16/Apr/2015:03:49:46 +0100] SEARCH REQ conn=8 op=244 msgID=245 base="ou=famrecords,ou=openam-session,ou=tokens,dc=openam,dc=forgerock,dc=org" scope=wholeSubtree filter="(&(objectClass=frCoreToken)(&(coreTokenString03=demo)(coreTokenString08=/test)))" attrs="ALL"

Therefore if the initial token was not created with exactly this string then it won't match the token on retrieval even though it was 'valid' at grant/auth time.

I think the most desirable solution to this would be to use a normalised or looked up version of the realm name when writing it to the new token. This will then be predictable/consistent when retrieved by something else later.