Return to Answer

Using the Authorization header seems like the right thing to do. It's the entire purpose of the Authorization header.

From http://tools.ietf.org/html/rfc7235#section-4.2 :

The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

If you have your own auth scheme document it, but there's no need to reinvent the wheel.

Using the Authorization header seems like the right thing to do. It's the entire purpose of the Authorization header.

From https://www.rfc-editor.org/rfc/rfc7235#section-4.2 :

The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

If you have your own auth scheme document it, but there's no need to reinvent the wheel.

To disagree with the accepted answer: using the Authorization header seems like the right thing to do. It's the entire purpose of the Authorization header.

From http://tools.ietf.org/html/rfc7235#section-4.2 :

The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

If you have your own auth scheme document it, but there's no need to reinvent the wheel.

Using the Authorization header seems like the right thing to do. It's the entire purpose of the Authorization header.

From http://tools.ietf.org/html/rfc7235#section-4.2 :

The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

If you have your own auth scheme document it, but there's no need to reinvent the wheel.

To disagree with the chosen answer: using the Authorization header seems like the right thing to do. It's the entire purpose of the Authorization header.

From http://tools.ietf.org/html/rfc7235#section-4.2 :

The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

If you have your own auth scheme document it, but there's no need to reinvent the wheel.

To disagree with the accepted answer: using the Authorization header seems like the right thing to do. It's the entire purpose of the Authorization header.

From http://tools.ietf.org/html/rfc7235#section-4.2 :

The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

If you have your own auth scheme document it, but there's no need to reinvent the wheel.