I have a ADF flow where I first retrieve an Oauth 2.0 token which then should be used in an Odata request.
This works perfect if I first extract the token and then hard code it in the auth headers(Bearer xxxxxxxx).
However I want to use a variable which I set earlier in the flow in this value. Like "Bearer [variable]". I have tried with the following: "Bearer #variables('Token')" but it doesnt work. I have double checked and the variable 'Token' is getting the correct token value so this should not be the problem.
enter image description here
So my question is whether it is possible to use variables in the Auth Header section?
I have tried to use "Bearer #variables('Token')" in the Value field for Auth Headers. This doesnt work unfortunately.
I reproduced the same thing in my environment and got this output
Create a web activity and generated a bearer token with a sample URL and Create a parameter variable with the name Token
Create a set variable and use this dynamic content value #activity('Web1').output.data.Token
*Then, I created a copy activity with Additional headers.
As suggested by #Scott Mildenberger*
Authorization: #concat('Bearer ', variables('token'))
Pipeline successfully executed and got the output:
We are trying to write a iRule for the BIG-IP universal persistence module.
Our mission is to extract and persist from a HTTP response payload/body an application unique identifier (something like a seesionid for us).
Then use it in a consecutive HTTP requests.
Note, this unique identifier return in text/xml/soap-xml response formats and there is no cookie involve here.
We're having problem to write the TCL code for the extraction of our custom unique identifier from the HTTP response payload/body.
We have checked these manuals and did not find example for this kind of functionality:
https://devcentral.f5.com/wiki/iRules.HTTP_RESPONSE.ashx
https://devcentral.f5.com/wiki/iRules.HTTP__payload.ashx
Thanks.
Here's an example with jsession IDs that should get you started with basic persistence flow, and this example gives you an idea on how to work with payload data.
I seem to be getting intermittent results back from our OnDemand Jira instance's REST API.
If I properly set the Authorization header to 'Basic [base64login]' & the Content-Type header to 'application/json', and then issue a GET to http://[installation].atlassian.net/rest/api/2/project I get different results each time.
The first result always seems to be an empty JSON array ([]). Subsequent calls seem to work as expected for the most part, but occasionally I get an empty response. Also, if I enter invalid credentials I get an empty response rather than an error / 401 / etc.
Is there some gotcha to using Basic Auth on OnDemand instances? Does it require the additional use of cookies or something else?
I have two questions:
Q1: Why does OAuth2 require params to be ordered and encoded (for 2-legged)?
All it has to worry about is the matching signature in both the end for the given data(query string).
We can just check the signature generated using the query string.(e.g ?a=1&b=2). Since the signature is generated based on the secret key which is known only to the client and provider, we can only consider the query string without any ordering/encoding.
So, what's the advantage in doing ordering/encoding and then creating the signature?
Q2: How can this signature save me from man-in-the middle attack?
If I have to make a request like this to my server from a client:
increaseUserPoints?userId=1&pointsToAdd=5&appId=x&token=XYZ
Now the token XYZ will be always same, so a hacker could keep posting the same request to increase points. Since the generated token from the given appId is the same, the server will allow this. How is this case handled?
Q1: Ordering the query parameters brings sanity to the HMAC.
Let's say you have two parameters: 'pointsToAdd' and 'appId'. Using the query string pointsToAdd=X&appID=y creates a different HMAC to appID=y&pointsToAdd=X. Because both you and the server need to generate the same HMAC to verify the requests having unordered query parmeters plain fails.
Q2: This saves you from an attack because only you and the server know how to sign your request.
You have a secret key, and only you and the server knows it. This key signs the request. If the HMAC doesn't match according to this secret key, the request fails.
Because all parameters have been used to create the HMAC the request is secure from MITM attacks — a hacker can't change, add or delete any query parameters, or the server will produce a different HMAC when it attempts to authorise and the request fails.
How many characters long can an oauth access token and oauth access secret be and what are the allowed characters? I need to store them in a database.
I am not sure there are any explicit limits. The spec doesn't have any.
That said, OAuth tokens are often passed as url parameters and so have some of the same limitations. ie need to be properly encoded, etc.
OAuth doesn't specify the format or content of a token. We simply use encrypted name-value pairs as token. You can use any characters in token but it's much easier to handle if the token is URL-safe. We achieve this by encoding the ciphertext with an URL-safe Base64.
As most people already pointed out. The OAuth specification doesn't give you exact directions but they do say...
cited from: https://datatracker.ietf.org/doc/html/draft-hammer-oauth-10#section-4.9
"Servers should be careful to assign
shared-secrets which are long enough,
and random enough, to resist such
attacks for at least the length of
time that the shared-secrets are
valid."
"Of course, servers are urged to err
on the side of caution, and use the
longest secrets reasonable."
on the other hand, you should consider the maximum URL length of browsers:
see: http://www.boutell.com/newfaq/misc/urllength.html
If you read the spec, it says,
The authorization server issues the registered client a client
identifier - a unique string representing the registration
information provided by the client. The client identifier is not a
secret; it is exposed to the resource owner, and MUST NOT be used
alone for client authentication. The client identifier is unique to
the authorization server.
The client identifier string size is left undefined by this
specification. The client should avoid making assumptions about the
identifier size. The authorization server SHOULD document the size
of any identifier it issues.
Second, Access Token should be sent as header, not as a URL param.
Authorization: Bearer < token>.
An OAuth token is conceptually an arbitrary-sized sequence of bytes, not characters. In URLs, it gets encoded using standard URL escaping mechanisms:
unreserved = ALPHA, DIGIT, '-', '.', '_', '~'
Everything not unreserved gets %-encoded.
I'm not sure whether you just talk about the oauth_token parameter that gets passed around. Usually, additional parameters need to be stored and transmitted as well, such as oauth_token_secret, oauth_signature, etc. Some of them have different data types, for example, oauth_timestamp is an integer representing seconds since 1970 (encoded in decimal ASCII digits).
Valid chars for OAuth token are limited by HTTP header value restrictions as OAuth token is frequently sent in HTTP header "Authorization".
Valid chars for HTTP headers are specified by https://www.rfc-editor.org/rfc/rfc7230#section-3.2.6. Alternatively you may check HTTP header validating code of some popular HTTP client libs, for example see Headers.checkNameAndValue() util of OkHttp framework: https://github.com/square/okhttp/blob/master/okhttp/src/main/java/okhttp3/Headers.java
And this is not all. I wouldn't include HTTP header separator (; and many others) and whitespace symbols (' ' and '\t') and double quote (") (see https://www.rfc-editor.org/rfc/rfc7230#section-3.2.6) as it would require to escape OAuth token before using in HTTP header. Frequently tokens are used by humans in curl test requests, and so good token generators don't add such characters. But you should check what characters may produce Oauth token generator with which your service is working before making any assumptions.
To be specific, even if Oauth spec doesn't say anything, if you are using java and mysql then it will be 16 characters as we generally generate the tokens using UUID and store it as BINARY(16) in the database. I know these details as I have recently done the development using OAuth.