There three aspects..
1. Protect the confidentiality of the token at rest (in storage)
2. Protect the confidentiality of the token in transit.
3. Protect the confidentiality of the token from the client.
[2] is achieved through TLS.
[3] this is the one which mentioned in the spec. This is needed if we have
to include certain information in to the token that should not be visible
to the client.
Doing [3] is very costly. What client gets there is an encrypted token. So
- its the same encrypted token that it will send to access resources. So -
for each request we need to decrypt it.
Also the issue in [3] is - if you store the encrypted token in the database
- somebody having access to the database - can take the encrypted token and
use it to access the API (he does not need to decrypt it).
What I would suggest is this.
In the access token we issues we have some information parts and a secret
part.
Information part is something like domain name.. like wise. Secret part is
the randomly generated string.
Access Token = INFORMATION_PART + SECRET_KEY
This is what I suggest..
Access Token = Base64Encode(INFORMATION_PART + ":" + SECRET_KEY)
Client will get the Access Token and we store *Hash(SECRET_KEY)* in the
database (no encryption)
Now - when accessing the API client will send the Access Token
Decoded Access Token = Base64Decode(Access Token)
= INFORMATION_PART + ":" + SECRET_KEY
Now to validate the token we check, *Hash(SECRET_KEY{from request}) = **Hashed
Secret Key from database*
This way we do not want to worry about encryption - and we also do not
store access token in clear text in the database.
Refresh token can be just stored as a hash.
Thanks & regards,
-Prabath
On Fri, Jul 26, 2013 at 2:59 PM, Sumedha Rubasinghe <[email protected]>wrote:
> We need to attend to $subject.
>
> OAuth2 spec also recommends this in it's Threat Mitigation section.
>
> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-4.2
> "For those cases where the client is prevented from observing the contents
> of the token, token encryption MUST be applied in addition to the usage of
> TLS protection."
>
> Some design considerations.
> 1. Should be configurable (default off), configured via identity.xml
> 2. Need to consider token validation flow as well (hash should be
> generated of incoming token & compared)
> 3. Should we also store encrypting algorithm as well? (for backward
> compatibility if it changes after sometime) - Is this a real scenario?
>
>
>
>
> --
> /sumedha
> b : bit.ly/sumedha
>
--
Thanks & Regards,
Prabath
Mobile : +94 71 809 6732
http://blog.facilelogin.com
http://RampartFAQ.com
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
