13

A request using the Authorization: bearer [token] can be used for authentication?

or

Should we use another method to authenticate a client and issue a token then use the token as a bearer token like OAuth2 does? Why popular web services(e.g. Github, AWS, Google..) uses other method(like AWS does: Authorization: AWS4-HMAC-SHA256 Credential=...) to authenticate a client. The point of the question is: is there any valunerables or violation of standards in the following flow or not.

I would like to use the following flow:

the client: which is like Twitter client.
the server: which is like Twitter API.

  1. the client makes the token(encrypted user ID, password, and etc).
  2. the client requests a resource to the server with Authorization: bearer [token].
  3. the server decrypts the token and authenticates the client.
  4. the server response the resource.

I read the following RFC but I haven't found any reason why I shouldn't or should use the flow above.

https://www.rfc-editor.org/rfc/rfc7235
https://www.rfc-editor.org/rfc/rfc6750

Thanks

Community
  • 1
  • 1
sndyuk
  • 2,720
  • 2
  • 24
  • 32
  • 1. Not sure how are you going to 'make' token on client side? 2. Are you going to send username password (in encrypted form) with each request? – Vivek Athalye Mar 08 '17 at 16:54
  • @VivekAthalye 1. Yes, each clients make token. 2. Yes, like basic authentication. – sndyuk Mar 09 '17 at 13:55
  • 1
    I just wanted to say I'm impressed that someone used the not equal sign. Kudos. – Jhecht Mar 15 '17 at 00:19

3 Answers3

5

I would recommend to stick to the OAuth2 spec. If you want to use a username and password to obtain a token you should use the "Client Credentials" flow. That means you need an "https" endpoint where the user can obtain an access token through the following POST request:

POST /token HTTP/1.1
Authorization: Basic base64_encode("username:password")
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

If the client credentials are valid the endpoint should create an access token on the server. Beside the token you should store who has obtained the token and a timestamp when the token expires. So the token should not be the username and password encrypted like in your example instead it should be a random string which is assigned to the user.

The access token can then be used by the client to access protected parts of your API. If your API receives an bearer token you can look up the assigned user in your token table.

That being said in OAuth2 you typically get an access token though an app key and secret which you have obtained previously by the API provider. This has the advantage that the user does not need to share any credentials with an 3rd party app. But whether this is needed depends on your use case.

Christoph Kappestein
  • 401
  • 3
  • 7
  • Thanks, I would use the OAuth2 if I want to keep an authentication method separate from a resource server. But I feel the OAuth2 is over-spec. – sndyuk Mar 09 '17 at 14:03
  • When you have a typical company then authentication on a server is normally then delegated to an ldap server. So in this case you already have 3 parties (client, server, auth server ldap). From this point moving to OAuth is not additional overhead. It even frees the server from the need to be attached to ldap. – Christian Schneider Feb 14 '19 at 13:04
2

Why popular web services(e.g. Github, AWS, Google..) uses other method(like AWS does: Authorization: AWS4-HMAC-SHA256 Credential=...) to authenticate a client.

AWS signature header is not based only on client credentials, it also includes bits derived from the request itself, as well as current time. Net effect is that not only client identity is verified, but the request content as well, so someone wouldn't be able to use the signature on another request (or modify the request in flight), even if they managed to obtain the signature somehow. Including current time makes the signature valid for only limited period, mitigating replay attacks.

weirdan
  • 2,499
  • 23
  • 27
1

The bearer token from an OAuth2 server shouldn't be used as direct means of authentication. They don't represent an end-user, but instead reprsent the authorization a client has to act on behalf of that user. Their article clearly explain why.

If you want to implement your own Othentication server, you can use OpenID Connect. It's a standard built on top of OAuth 2.0. OIDC leverages the bearer token in a way that ensures authentication.

They have a list of certified libraries you can use to implement your server. Or you can leverage one of the MANY prexsiting IODC providers

ZeroUltimax
  • 256
  • 1
  • 9