In my dataflow configured in Apache Nifi, I have an API that requires Authorization header (bearer token) to invoke with a GET request.
I'm trying to configure the InvokeHTTP processor for this, but it doesn't support Authorization headers by default.
How can I add the Authorization header (maybe as an Attribute) into the GET request using Nifi's InvokeHttp processor?
You can add as many "dynamic properties" to the processor config as you like and they will be passed as HTTP headers on the request. You can populate the token via parameter or general Expression Language in the property value, but be aware that if using variables/parameters, you won't be able to use sensitive parameters because those must be referenced exactly rather than combined, and in this case you'll need to prepend the value with Bearer . There is an open ticket to make authorization header usage (OAuth2 specifically) easier with this processor.
Related
I'm writing a service which requires OIDC. I've seen a number of client libraries (the programming language and library here is irrelevant) which allow auto-refreshing/re-fetching the content at the "jwks_uri" endpoint which is defined in the discovery document at the IdP's "/.well-known/openid-configuration" endpoint.
I know the content defined at the actual "jwks_uri" endpoint can change. But can the value of this "jwks_uri" (the URI itself) change in the discovery document? I can't seem to find any answer in the specs.
Yes it can be cached. For example some clients (like in .NET) do for example cache this information (including the singing keys) and refresh this information every 24 hours.
If you validate your token remotely (in the IDP side) yes you can cache the content of .Well-known for ever, in the most case the endpoints of your IDP will never change, but if you validate your token locally, you need the last keys in IDP side, and you need to know the frequency change of keys in your IDP, basing on that you can cache your keys.
The rfc explicitly requires that token is passed in body only if content type is form-url-encoded
What the reason behind it? Why not permit multipart?
Workarounds:
This poses a problem for file uploads where the browser sets the content type to multiparty/form-data
The most common solution is to pass the token in the query string, which is insecure for logs or appearance in history.
The preferred method is to use the Authorization header to send the access token. The body and URL variants are in the spec to enable OAuth to clients which cannot, for some reason set the HTTP header value. In order to limit the possibilities the server would have to process the standard limits usage to only form-url-encoded. You can read some more about the problems that can arise from this in this answer: Why do we prefer Authorization Header to send bearer token to server over other techniques like URL encoding
In short - it would have been much more complicated for the resource servers in order to support receiving an access token using different content-types. I believe this the main reason behind this decision (although there might be some security implications I'm not aware of).
so generally, the best solution would be to pass the token in an Authorization header, instead of the body or URL.
I'm in the process of applying swagger to a project of mine.
In terms of Authorization, the user can log in with email and password and they'll get an authorization token.
They're then supposed to send this token along with every call, in the header.
So it would be like: MyAuthorization: authKey
Looking at the swagger documentation, it seems that it is only set up to handle OAuth. Is there a way to have swagger handle the authentication my way? I mean in the generated code. I can generate code for the project, it just only has "Basic: ..." as an option.
I'm running swagger 1.3.6, can't upgrade due to dependencies.
From the Swagger 1.2 specs
You can define an authorization object which specifies you are using
a type of "apiKey"
a passAs of "header", to indicate the key is passed in the request header
a keyname of "MyAuthorization", or whatever your header is
I'm writing my own codes for the OpenID Connect protocol. Basically, I intend to write my own provider and related stuff on Google App Engine's platform using Jersey and Google's datastore via Objectify library.
I'm in the middle of implementing the (access/refresh) token endpoint and there's this client authentication that I need to take care of. I'm just wondering if there are preset authentication schemes' keywords that I could send if in case the client did not have client_secret_basic set during the registration process (or whatever's set in the datastore entry.)
For a failed client authentication with the following methods, the scheme is used as response in the WWW-Authenticate header (401):
client_secret_basic: Basic,
client_secret_post: ???,
client_secret_jwt: ???,
private_key_jwt: ???,
none: obviously none.
I've looked at some open source implementations, nimbus' and OAuth-Apis', but they don't seem to handle this minor issue (they only respond with the generic error response defined in OAuth2 rfc6749#section-5.2.)
If there are no predefined keywords, then I suppose I'll have to make up my own. But it would be great if they exist.
The authoritative list for these is at IANA. There, you can find these handfuls:
Basic
Bearer
Digest
HOBA
Mutual
Negotiate
OAuth
SCRAM-SHA1
SCRAM-SHA-256
vapid
Which of these is client_secret_post, client_secret_jwt and private_key_jwt? None. You'll need to map those to one from the registered list above or return your own values. Better yet, you can submit a draft to the OAuth working group or the OpenID Foundation to get the above IANA registry updated with something that makes sense for these missing cases. Then, we can all interop :-)
I feel silly even asking this question, but am at the limits of my understanding, and am hoping someone can provide some context.
I'm looking at the following (https://stormpath.com/blog/token-auth-for-java/) which states:
The access_token is what will be used by the browser in subsequent requests... The Authorization header is a standard header. No custom headers are required to use OAuth2. Rather than the type being Basic, in this case the type is Bearer. The access token is included directly after the Bearer keyword.
I'm in the process of building a website, for which I'll be coding both the back-end REST service, as well as the front-end browser client. Given this context, why do I need to follow any of the guidelines given above? Instead of using the access_token, Authorization and Bearer keywords, what's stopping me from using any keywords I like, or skipping the Bearer keyword entirely in the header? After all, as long as the front-end and back-end services both read/write the data in a consistent manner, shouldn't everything work fine?
Are the keywords and guidelines given above merely best-practice suggestions, to help others better understand your code/service? Are they analogous to coding-styles? Or is there any functional impact in not following the above guidelines?
Given this context, why do I need to follow any of the guidelines given above?
Because they are standardized specifications that everyone is meant to conform to if they want to interact with each other.
Instead of using the access_token, Authorization and Bearer keywords, what's stopping me from using any keywords I like, or skipping the Bearer keyword entirely in the header?
Nothing, except that it won't be OAuth anymore. It will be something custom that you created for yourself that noone else will understand how to use, unless you publish your own spec for it.
After all, as long as the front-end and back-end services both read/write the data in a consistent manner, shouldn't everything work fine?
Who is to say that you alone will ever write the only front-end? Or that the back-end will never move to another platform? Don't limit yourself to making something custom when there are open standards for this kind of stuff.
Are the keywords and guidelines given above merely best-practice suggestions, to help others better understand your code/service?
No. They are required protocol elements that help the client and server talk to each other in a standardized manner.
Authorization is a standard HTTP header used for authentication. It has a type so the client can specify what kind of authentication scheme it is using (Basic vs NTLM vs Bearer, etc). It is important for the client to specify the correct scheme being used, and for the server to handle only the schemes it recognizes.
Bearer is the type of authentication that OAuth uses in the Authorization header. access_token is a parameter of OAuth's Bearer authentication.
If you use the Authorization header (which you should), you must specify a type, as required by RFCs 2616 and 2617:
Authorization = "Authorization" ":" credentials
credentials = auth-scheme #auth-param
auth-scheme = token
auth-param = token "=" ( token | quoted-string )
So, in this case, Bearer is the auth-scheme and access_token is an auth-param.
Are they analogous to coding-styles?
No.
Or is there any functional impact in not following the above guidelines?
Yes. A client using your custom authentication system will not be able to authenticate on any server that follows the established specifications. Your server will not be able to authenticate any client that does not use your custom authentication system.