Bearer Authorization header and how to handle

[mds1256]

I am wanting to pass over the access token in an authentication header for an API I am creating (learning) and I have read that the authorization header should have a value of 'Bearer aTokenStringHere'.

 

What is the best way of getting this header value and parsing it, is it just the case of getting the Authorization header form the request and then stripping out the Bearer part of the string? and leaving the token value and then using that?

 

Also can you explain why we must use Bearer as part of the value for Authorization header?

 

Thanks

[requinix]

Get it from the HTTP_AUTHORIZATION header in $_SERVER, then do rudimentary string operations on it.

if (isset($_SERVER["HTTP_AUTHORIZATION"])) {
	list($type, $data) = explode(" ", $_SERVER["HTTP_AUTHORIZATION"], 2);
	if (strcasecmp($type, "Bearer") == 0) {
		// use $data
	} else {
		// ???
	}
} else {
	// ???
}

Bearer is a not yet official method of authorization that people made up a while back because Basic and Digest weren't working well enough. It just means that whatever token comes after is some special code that the server will recognize for authentication - what actually happens with it is up to you.

[mds1256]

Get it from the HTTP_AUTHORIZATION header in $_SERVER, then do rudimentary string operations on it.

if (isset($_SERVER["HTTP_AUTHORIZATION"])) {
	list($type, $data) = explode(" ", $_SERVER["HTTP_AUTHORIZATION"], 2);
	if (strcasecmp($type, "Bearer") == 0) {
		// use $data
	} else {
		// ???
	}
} else {
	// ???
}

Bearer is a not yet official method of authorization that people made up a while back because Basic and Digest weren't working well enough. It just means that whatever token comes after is some special code that the server will recognize for authentication - what actually happens with it is up to you.

 

 

Ah, I see - thanks for this it makes it very clear!

 

I know its good practice to use this already existent header but is there any reason why I couldn't create my own headers and use these, e.g. access_token and refresh_token?

 

On a slightly different note:

 

Looking at the Oauth that seems to have a client id and a client secret passed in the http authorization header and then the access/refresh token passed in to the post body - what is the advantage of having a client id and secret as well as the access tokens? 

 

Is it the case that this controls which 'application' can use the endpoint?

[Jacques1]

I know its good practice to use this already existent header but is there any reason why I couldn't create my own headers and use these, e.g. access_token and refresh_token?

 

Nothing prevents you from creating custom headers, as long as they don't collide with existing ones. Whether it's sensible to invent your own protocol is a different story.

 

 

 

Looking at the Oauth that seems to have a client id and a client secret passed in the http authorization header and then the access/refresh token passed in to the post body - what is the advantage of having a client id and secret as well as the access tokens?

 

You misunderstand. The client credentials are exchanged for the access token. You send the credentials, you get a token. Passing the access token in the “POST body” doesn't even make sense, because it implies that every single request must be a POST request (what about GET?).

 

Anyway, I think we've already discussed this in great detail, but there doesn't seem to be much progress. Maybe it makes more sense if you sit down, define your goals and then choose the appropriate implementation. If you randomly go through different protocols and variants, that only leads to more confusion.

Edited January 20, 2017 by Jacques1

[mds1256]

 

You misunderstand. The client credentials are exchanged for the access token. You send the credentials, you get a token. Passing the access token in the “POST body” doesn't even make sense, because it implies that every single request must be a POST request (what about GET?).

 

Anyway, I think we've already discussed this in great detail, but there doesn't seem to be much progress. Maybe it makes more sense if you sit down, define your goals and then choose the appropriate implementation. If you randomly go through different protocols and variants, that only leads to more confusion.

 

 

Ok so the test OAuth2 server i have created must have the following provided in order to provide the access token:

 

1. header - grant_type = password

2. header - username

3. header - password

4. Authorization header - client id:client secret

 

otherwise it wont issue an access token.

 

So what I am confused over is why do you need to provide a username and password and also a client id and client secret? Why not just authenticate with the username and password?

[Jacques1]

Because OAuth distinguishes between the client (application) and the resource owner (e. g. a human user). The client credentials authenticate the client, the username/password authenticate the human user. Client authentication is not always required as per protocol, but the specific variant you've chosen or the implementation may still enforce it.

 

But then again: It's entirely unclear what you're event trying to achieve. In your previous threads, you wanted to more or less get rid of the password entirely. Now you appearently want only password authentication, which would make the whole OAuth protocol rather useless.

 

Forget about the technical stuff for now. What is your goal? What are the parties, how do they interact, and how is your application supposed to work?

[mds1256]

Because OAuth distinguishes between the client (application) and the resource owner (e. g. a human user). The client credentials authenticate the client, the username/password authenticate the human user. Client authentication is not always required as per protocol, but the specific variant you've chosen or the implementation may still enforce it.

 

But then again: It's entirely unclear what you're event trying to achieve. In your previous threads, you wanted to more or less get rid of the password entirely. Now you appearently want only password authentication, which would make the whole OAuth protocol rather useless.

 

Forget about the technical stuff for now. What is your goal? What are the parties, how do they interact, and how is your application supposed to work?

 

That makes sense - so you can forbid a client APP but still allow a user - for example you release two applications which can authenticate using the same user details but then you retire one of the apps so you would then remove that Client id from the allowed list which prevents the app from working with the API but still allowing the other APP access.

 

The goal is to create a mobile app that authenticates with a back end to using tokens - the user first logs into the mobile app using a username and password which will send off a request for a token - the server will response with the token if the details are correct and then the mobile app will record the token and send this in each request to the server.

 

The part i was struggling with was why do i need a client id and secret as well as a username and password - but i guess if i want to control the client app access as well as the user access this is why i need the two. Can you confirm that this thought is correct?