In JAVA based application, we are receiving JWT token through Authoriztion HttpHeader. As I know HttpHeader can contains multiple value against one Header Key.
So here want to know whether the Authoriztion http header can also contains multiple bearer token value in same header ? I know Authorization header can contains multiple token of different type like Basic, Bearer etc.
But can it also contains multiple same type of token as value ?
as example: (Whether it is valid or not)
"Authorization" : "Bearer XXXXXX1, Bearer XXXXX2"
Any RFC reference will be helpful.
TLDR; It's possible and some server could be handling it but it's not RFC valid.
Long answer:
This can be valid, as defined in RFC7230, section 3.2.2, Field Order:
A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation of the combined field value; a proxy MUST NOT change the order of these field values when forwarding a message.
Each "Bearer XXXX" should be considered as separate field-value.
So some servers may be able to handle it ...
... But the "Authorization" RFC (RFC7235, Appendix C) adds more rules specificaly for the Authorization header
Authorization = credentials
credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
*( OWS "," [ OWS auth-param ] ) ] ) ]
auth-param = token BWS "=" BWS ( token / quoted-string )
So it seems you shouldn't be able to contains multiple token of different type like Basic, Bearer etc. As it accept only one auth-scheme
The RFC for Bearer (RFC6750 section2.1) is even more simple
b64token = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token
So it can contain multiple values of the same or different scheme, some server will accept it because it's a valid header,but it will not be RFC valid because the Authorization header is more restrictive.
Related
I'm using springfox-swagger 3.0.0 to generate the Swagger UI (so I don't have much control over the Swagger UI code), and for my oauth2 authorization I've defined an application flow.
security: {
key: "OAuth2";
value: {
type: TYPE_OAUTH2;
flow: FLOW_APPLICATION;
token_url: "/oauth2/token";
scopes: {
scope: {
key: "api"
value: "Grants access to api"
}
}
}
}
Now my problem is that the client ids my system uses, contains colon ":" characters, which are also use to separate client id from client secret in the authorization header. This messed up the logic at the token endpoint.
authorization: Basic YXBpOjk1NmZkYmEzLWE1ZmEtNDk0MS1iZDAzLWY3NGY0ZmNhYjM1ZjpzWFNXVlBpcklSN1dsUkRvOG9lNFM2VTR3OEI0VFg4VUUwNm9QR2FyWmVn
If I URL encode my client id value before passing it to the client_id field in the swagger console, everything works ok.
authorization: Basic YXBpJTNBOTU2ZmRiYTMtYTVmYS00OTQxLWJkMDMtZjc0ZjRmY2FiMzVmOnNYU1dWUGlySVI3V2xSRG84b2U0UzZVNHc4QjRUWDhVRTA2b1BHYXJaZWc=
Any idea how can I instruct swagger to URL encode the client id field value before packaging it in the header?
Thanks
You'll have to fork Swagger UI and implement the necessary change in your fork. Then, since you're using Springfox, you'll need to point it to your custom Swagger UI fork instead of the bundled version.
The code that constructs the Authorization header for OAuth requests lives here:
https://github.com/swagger-api/swagger-ui/blob/master/src/core/plugins/auth/actions.js
Tweak either the authorizePassword or authorizeApplication function (depending on your grant type) to percent-encode the clientId:
Authorization: "Basic " + btoa(encodeURIComponent(clientId) + ":" + clientSecret)
I am trying to follow the guide to generate Oauth authentication tokens for YAHOO DSP API.
Base64 encoding is a way of encoding binary data into text so that it can be easily transmitted across a network without error.
In this step, you will take the client ID and client secret that the YDN console generated for you and encode them using the base64 protocol. You can use an online encoding service like base64encode.org.
No matter which service you use, ensure that no spaces are appended to the CLIENT_ID and CLIENT_SECRET keys and separate the CLIENT_ID and CLIENT_SECRET with a colon, i.e. CLIENT_ID:CLIENT_SECRET.
The generated value will now be referenced as ENCODED(CLIENT_ID:CLIENT_SECRET) in this guide.
An example is given:
CLIENT_ID = dj0yJmk9N2pIazlsZk1iTzIxJmQ9WVdrOWVEUmpVMFpWTXpRbWNHbzlNQS0tJnM9Y29uc3VtZXJzZWNyZXQmeD00NA–
CLIENT_SECRET= a7e13ea3740b933496d88755ff341bfb824805a6
AUTHORIZATION = ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5BLS06YTdlMTNlYTM3NDBiOTMzNDk2ZDg4NzU1ZmYzNDFiZmI4MjQ4MDVhNg==
Using the recommended website I get the wrong AUTHORIZATION.
I have tried both encoding the whole thing at once ie. encode(CLIENT_ID:CLIENT_SECRET), and each element individually encode(CLIENT_ID):encode(CLIENT_SECRET).
Attempt encoding whole thing:
ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5B4oCTOiBhN2UxM2VhMzc0MGI5MzM0OTZkODg3NTVmZjM0MWJmYjgyNDgwNWE2
Attempt encoding each element:
ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5B4oCT:YTdlMTNlYTM3NDBiOTMzNDk2ZDg4NzU1ZmYzNDFiZmI4MjQ4MDVhNg==
Expected result:
ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5BLS06YTdlMTNlYTM3NDBiOTMzNDk2ZDg4NzU1ZmYzNDFiZmI4MjQ4MDVhNg==
The difference between 'each element' and the expected result is only a few characters corresponding to the end of client_ID and the colon.
B4oCT: should be BLS06.
Links to full documentation:
https://developer.yahoo.com/dsp/api/docs/authentication/tokens.html
https://developer.yahoo.com/dsp/api/docs/traffic/info/sandbox.html
Update:
The final character of Client_ID is '–' . This is some sort of non-standard character that is interpreted as two dashes i.e.'--' in utf-8 and windows 1258.
One different, TO NOTE is, that when you decrypt the expected output you will get your client id as
dj0yJmk9N2pIazlsZk1iTzIxJmQ9WVdrOWVEUmpVMFpWTXpRbWNHbzlNQS0tJnM9Y29uc3VtZXJzZWNyZXQmeD00NA--
instead of
dj0yJmk9N2pIazlsZk1iTzIxJmQ9WVdrOWVEUmpVMFpWTXpRbWNHbzlNQS0tJnM9Y29uc3VtZXJzZWNyZXQmeD00NA–
NOTE, there are two "-" at the end.
OAuth client auth token is always generated using Base64 encoding with following format
Base64_Encoding(CLIENT_ID:CLIENT_SECRET)
Most of the usage perform this Base64 encoding with encoding type as "UTF-8".
It looks like, Yahoo requires this token with different encoding. On "https://www.base64encode.org/" if you try to encode your "CLIENT_ID:CLIENT_SECRET" with "Windows-1254" as destination charset, you will receive the expected result. So, it looks like both encoding and decoding here is done keeping "Windows-1254" charset in place.
In DjangoRestFramework you can change keyword in header for token authentification.
From docs
Note: If you want to use a different keyword in the header, such as
Bearer, simply subclass TokenAuthentication and set the keyword class
variable.
What is the purpose of changing default keyword?
I've seen 'Bearer', 'Basic' and a few other variants, but just don't understand the purpose of doing so.
Can anyone explain?
I found how we need to pass the keyword to TokenAuthentication.
class BearerAuthentication(authentication.TokenAuthentication):
'''
Simple token based authentication using utvsapitoken.
Clients should authenticate by passing the token key in the 'Authorization'
HTTP header, prepended with the string 'Bearer '. For example:
Authorization: Bearer 956e252a-513c-48c5-92dd-bfddc364e812
'''
keyword = 'Bearer'
Then instead of using authentication.TokenAuthentication in the settings.py we will use BearerAuthentication
# settings.py
REST_FRAMEWORK = {
'DEFAULT_AUTHENTICATION_CLASSES': (
'your.models.BearerAuthentication',
)
}
Many web servers support multiple methods of authorization. In those
cases sending just the token isn't sufficient.
Source
The HMAC-SHA1 signature method requires a key formed with the concatenation of the client shared secret, '&' and the token shared secret.
I wonder which value should I use for the token shared secret when the client still does not have the request or access token: the client shared-secret again or leave it empty.
From the specification:
3.4.2. HMAC-SHA1
The "HMAC-SHA1" signature method uses the HMAC-SHA1 signature
algorithm as defined in [RFC2104]:
digest = HMAC-SHA1 (key, text)
The HMAC-SHA1 function variables are used in following way:
text is set to the value of the signature base string from
Section 3.4.1.1.
key is set to the concatenated values of:
1. The client shared-secret, after being encoded
(Section 3.6).
2. An "&" character (ASCII code 38), which MUST be included
even when either secret is empty.
3. The token shared-secret, after being encoded
(Section 3.6).
digest is used to set the value of the "oauth_signature" protocol
parameter, after the result octet string is base64-encoded
per [RFC2045], Section 6.8.
Thanks
The key should be set to the client shared-secret plus the "&" character when the token shared-secret is unavailable.
I am using oauth to authenticate dropbox and download a file from dropbox after getting access_token am using the below signature for download a file from dropbox am passing the root, path of the file, consumerKey and oauth_token with signature_method as PLAINTEXT and am getting an error
{"error": "Bad oauth_signature for oauth_signature_method 'PLAINTEXT'"}
Signature am using is given below :
https://api-content.dropbox.com/1/files?oauth_consumer_key=twcek2m7cxtantc&oauth_signature_method=PLAINTEXT&oauth_token=1jczc39y7rn1265&oauth_version=1.0&path=test%2Fut.txt&root=dropbox&oauth_signature=fbs34nykryouuj1%2526gbwmn3e27g97cfy
What should I do to resolve this error?
I was searching about this and found that:
1) The PLAINTEXT method does not provide any security protection and SHOULD only be used over a secure channel such as HTTPS. It does not use the Signature Base String.
2) The Service Provider declares support for the HMAC-SHA1 signature method for all requests, and PLAINTEXT only for secure (HTTPS) requests.
3) When used with PLAINTEXT signatures, the OAuth protocol makes no attempts to protect User credentials from eavesdroppers or man-in-the-middle attacks. The PLAINTEXT signature algorithm is only intended to be used in conjunction with a transport-layer security mechanism such as TLS or SSL which does provide such protection. If transport-layer protection is unavailable, the PLAINTEXT signature method should not be used.
You can refer this link http://oauth.net/core/1.0/#anchor22
You can also check if your keys are correct
The signature Protocol Parameters are set with the following values unencrypted:
oauth_signature_method : Set to PLAINTEXT.
oauth_signature : Set to the concatenated encoded value of the oauth_consumer_secret parameter and the value of the oauth_token_secret parameter. If the values contain a . character (ASCII code 46), it must be encoded as %2E. The values are separated by a . character (ASCII code 46), even if empty. The result MUST not be encoded again.
For example, if the Consumer Key is dj.9rj$0jd78jf88 and Token Secret is jjd999(j88ui.hs3, the encoded values are:
Consumer Key : dj%2E9rj%240jd78jf88
Token Secret : jjd999%28j88ui%2Ehs3
And the oauth_signature value is dj%2E9rj%240jd78jf88.jjd999%28j88ui%2Ehs3. This value is not encoded anymore and is used as it in the HTTP request. If the Token Secret is empty, the value is dj%2E9rj%240jd78jf88. (the separator . is retained).