I am writing some Java REST APIs which will be invoked from Web Hook configured through JIRA administration console. But, I do not see any way to add authentication header while configuring web hook in JIRA.
Without header, there is security concern in the sense that any one can invoke my Java REST APIs.
Could someone please suggest here how to add custom headers in web hook with possibly some example. I have already gone through Atlassian develper documentations but do not find any solution over there.
Adding a username and password to the Jira Cloud webhook URL e.g.
http://user:password#mycallbackurl.com
is ignored by Jira Cloud unfortunately. It seems that other Atlassian products do provide the ability to set a header / provide username and password for basic authentication.
Also see:
https://jira.atlassian.com/browse/JRA-31953
https://answers.atlassian.com/questions/12270170/where-does-the-webhook-arrive-from.
You basically have two options:
You can add an API key or some kind of secret to the webhook URL. The disadvantage is that the secret could show up in your web server logs.
Don't trust the webhook POST body (JSON) and pull the information from the API.
Adding the Atlassian server IPS to a white list would also make sense:
https://confluence.atlassian.com/cloud/database-and-ip-information-744721662.html#DatabaseandIPinformation-IPAddressrange.
Although it doesn't completely eliminate attack vectors since attacks can also come from another Jira cloud environment.
There is no support to add extra header in JIRA webhook configuration. So, authentication header can not be added in webhook configuration.
To do the authentication, one way is
1) Retrieve User information from incoming JSON
2) Make JIRA REST API call to check user's authenticity
3) Deny or allow further processing based on result
Related
I want to develop an authentication mechanism for 3rd party applications using keycloak initial access tokens. But I want to do this only by using the access tokens that I have generated in the keycloak. For example, I will give a generated token to the user and allow him to log into the application. Is this possible? How can i do that?
Initial Access Token
First, I'm not sure it is a good idea to use "initial access token" for authorizing requests to your own resources. It might even not be allowed. As per the doc:
An initial access token can only be used to create clients
Second, don't use keycloak libs for Spring as suggested in other answer. It is very deprecated.
Last, a REST API secured with Oauth2 is a resource-server (and not a client). As so, the dependency should be spring-boot-starter-oauth2-resource-server. Spring doc is pretty extensive on the subject. You can also have a look at those tutorials for resource-server configuration (and OAuth2 definitions).
Once the resource-server (Spring REST API) is configured, clients will have to authorize their requests as normal for OAuth2: provide with an Authorization header containing a Bearer access-token (a JWT issued by Keycloak to the client with one of standard flows: client-credentials or authorization-code depending you need to authorize the client itself or a user behind it).
Edit
I might have misunderstood your need. If what you want is having new clients register themself programmatically on your Keycloak instance, then those clients will just issue a REST request to Keycloak server API with the "initial access token" in Authorization header as normal.
Once registered, those clients will be able to call you resource-servers as described in my initial answer.
I am building a private API which provides some data, I have already set CORS to only allow requests from my website, and that works, but there is a problem: a user can make the request with the chrome console from my website to the API and that request will succeed since the API has no real way to tell if the request comes from the code i have written.
So my question is: is there any way to tell that? is there any way to prevent users from making that request from my website to call the API and bypass the CORS?
You need to update your request model so that requests to the API come from the web server itself, rather than from a users client.
That way you can add authentication to the API and only allow requests that come directly from your web server. Then web server can then display those results to your users.
CORS is not a method for checking/enforcing authentication or authorisation. It is purely an additional security control to protect against browser-based security vulnerabilities (XSS etc).
All of the React Native Twitter Login Clients that I'm finding seem to be hard-coding the TWITTER_CONSUMER_KEY and TWITTER_CONSUMER_SECRET into the the client code, rather than relying on a server to generate tokens and/or a twitter redirect URL.
Is this safe? (e.g. couldn't a consumer then DOS the API with the TWITTER_CONSUMER_KEY, causing the app to be rate limited?)
Is this the correct way to do it?
Is there a better / more secure way?
According to twitter's documentation, it seems like this is NOT the correct way to do this:
"In the event that you believe that your API keys has been exposed, you should regenerate your API keys by following these steps" - Authentication best practices
Examples which specify that the consumer key/secret should be hardcoded:
https://rnfirebase.io/docs/v5.x.x/auth/social-auth#Twitter
https://github.com/GoldenOwlAsia/react-native-twitter-signin/blob/master/Example/TwitterButton.js#L14
Related questions:
Twitter consumer secret really a secret?
Is it a security vulnerability
Yes.
Your app can be rate limited or flagged as malware/spam etc.
Is there a better / more secure way?
Basically only to have your own site auth (oauth2) done correctly and proxy specific requests from your clients, after validation or a simplified locked down site API that is then translated to the Twitter API.
Why is this, Twitter app-only auth supports OAuth2, allows a secure negotiated handshake and then requests made using a Bearer token. In this mode you can make requests on behalf of your App, but without a logged in user. So can't post tweets or see private accounts or read DMs.
For user-auth, Twitter only support OAuth1 and both the App and User are authenticated, but using a model that assumed plaintext http, so can't share a single token. Every single request needs to be made using consumer key/secret and signing the request. So there isn't a way to do this from a javascript client safely.
Is this safe?
Absolutely not. A bad actor can get users to authenticate via Twitter to receive their token credentials and then use your app's consumer key/secret (which would be available in plain text) to masquerade as your app to do all kinds of nasty stuff.
Is this the correct way to do it?
Given the security vulnerability described above, no.
Is there a better / more secure way?
I'm currently in the process of trying to figure out how to securely achieve authentication with Twitter. This involved a lot of reading, but it appears as though it's simply not possible without your own backend. I'll try and explain why:
Your goal is to receive the user's email/Twitter-ID
To achieve (1), you need to send a request to the GET account/verify_credentials endpoint (https://developer.twitter.com/en/docs/twitter-api/v1/accounts-and-users/manage-account-settings/api-reference/get-account-verify_credentials).
To do (2), you need to provide an authorisation header, which is constructed out of several items, including the user's OAuth tokens as well as your app's consumer key/secret. More info here: https://developer.twitter.com/en/docs/authentication/oauth-1-0a/authorizing-a-request.
You retrieve the user's OAuth tokens using the 3-legged OAuth flow
described here: https://developer.twitter.com/en/docs/authentication/oauth-1-0a/obtaining-user-access-tokens. The first step of this process is to send a POST request to the oauth/request_token endpoint (https://developer.twitter.com/en/docs/authentication/api-reference/request_token).
This endpoint itself requires an authorisation header constructed using
your app's consumer key/secret.
Obviously you can't perform step (4) because that implies you would have your consumer secret available in the client; even if it's not hardcoded, it would have to be in memory at runtime, at some point
Once you have your own backend service, one option would be for your client app to open a browser and direct to an endpoint (let's call it /auth/twitter) on this service which will perform all the steps mentioned above.
This same service could also implement another endpoint (/auth/twitter/token) which handles requests to the callback URL, which you set in your Twitter app settings. This callback URL is used as part of the same 3-legged flow. This endpoint would have all the information needed to then go ahead and retrieve the user's email/Twitter-ID.
Finally, /auth/twitter/token can redirect to a custom URL which your client app would need to handle as part of its URL schemes. It can include enough information by way of parameters for your app to continue as needed post-auth.
I have a Lambda function which triggered by API Gateway service, however this API is accessed by front-end application, this application not requiring the users to login or sign up to use it.
However I would like to secure my API to allow only from my front-end application.
After my research I found that I can use custom authorization in API Gateway, this custom authorization will check the authorization header of the incoming request and validate it.
the question is, can I use Amazon Cognito for something like this(implicit grant type)?
if not what is the thing that the front-end application will send to me to be validated and how can I keep it always changeable, so no one can guess it?
Thank You.
You could check the headers, but if they're always the same, someone can send an HTTP request with those headers - from any client - and trick your Lambda into thinking it's coming from your UI.
Even if you generate a unique token every time your UI is loaded and include it in the headers, someone could take that token and send requests from another client as well.
You could build fancy JavaScript tricks to make headers more dynamic, but it would only make it harder to use your API from another client, not impossible.
I have a web service built with WebAPI that accepts JSON requests and responds accordingly. The core architecture is built but there isn't any authentication/authorization.
After a lot of googling and poking around sample projects, I'm not sure where to start. I've found a ton of material from 2008 and 2009 but not a whole lot of recent guides/workflows for WebAPI / single page apps. I think the workflow should be as follows:
Check to see if the user is logged in: How can this be done with javascript? Do I send a cookie to my webAPI? If so, do I send that cookie as a parameter in the body of the request?
Let the user log in / register: How is this data encrypted/decrypted? Surely I can't be sending passwords over the wire... is this where SSL comes in?
Provide them with access to what they have rights to access: I think I got this - I can just authorize in the controllers on a per-request basis.
Any info would be awesome.
Basically you need a token based authentication or authorization.
If you are referring to the ASP.NET WebAPI, the following project will be a great place to start:
http://thinktecture.github.com/Thinktecture.IdentityModel.45/
Even if you are not using ASP.NET WebAPI, the following video is a great introduction on how to provide authentication/authorization on RESTful web services:
http://vimeo.com/43603474
To answer some of your questions:
Check to see if the user is logged in: How can this be done with javascript? Do I send a cookie to my webAPI? If so, do I send that cookie as a parameter in the body of the request?
You can use a cookie but I normally use the header in order to avoid common XSRF attacks. Cookies are automatically included whenever a http request is sent from the browser.
is this where SSL comes in?
Yes. If you are going to go ahead with the token based approach, you can use a separate server (Identity Server) to do the authentication for you.
JavaScript clients are unique. Do you have the Web API and the page serving up JavaScript in the same domain? If not, you have same origin policy restrictions. If you have the same Web application hosting the web pages and Web API, you can use forms Authn. In that case, you don't need to send the cookie containing the authentication ticket yourself from JavaScript. Browsers do that for you and that is the cause of XSRF problem. You have to be careful about JavaScript sending credentials that the end user is not supposed to know. If JavaScript knows something, any intelligent end user can get to that knowledge. OAuth 2.0 implicit grant could be a good choice. The end user enters the credentials (password) in the authorization server which issues an access token. JavaScript gets the token and presents it to the web API but it will never have access to the credentials.