Moving Towards A Tokenized World For Trusted Access Rights

Like it or not, we are moving to a tokenized world, and where we pass tokens which are trusted to provide further information. This might relate to a login token for a corporate infrastructure, and where an access token can be passed to give rights to applications and files. The tokens themselves — if designed properly — will not actually reveal sensitive information (such as passwords and login IDs). If a token is signed with the private key of a trusted entity, we know that we can trust the token.

If you want to do access tokens correctly we can use SAML (Security Assertion Markup Language), or OAuth 2.0. Unfortunately, SAML is complex to implement properly, and so many companies have implemented OAuth 2.0 for access control. In its original form, OAuth 2.0 tried to reduce its dependency with an HTTPs connection and on digital signatures, but this has led to the poor protection of the secrets on the token and can also lead to token stealing. This is because the token is not actually signed by the trusted entity. While this keeps things simple, the tokens themselves cannot be fully trusted. The security built in was to use an HTTPs connection to pass the token back and define a time-out for the token.

And so HTTP from its humble HTTP 1.0 roots, with GET and POST, then provided us with RESTful Web services. Now it is supporting token binding with a new RFC: