I made a web api that does that follow services:
Returns the list of current job openings of the company (GET)
Apply on any job that is currently opened (POST).
The API is then consumed by an angularJS front end. Most of the authentications that I found from the web requires login but our website doesn't so I can't really use token bearer.
What are the list of things that I must implement or consider? are there any threats and how do I get around them?
You can probably add a ClientId/ClientSecret to your SPA and somehow securely send it as part of every request probably a AngularJs interceptor will help.
On the webAPI side accept only those requests that have a valid clientId, do that probably using a filter.
A similar infrastructure is explained here http://bitoftech.net/2014/07/16/enable-oauth-refresh-tokens-angularjs-app-using-asp-net-web-api-2-owin/ (clientId,ClientSecret part)
Hope this helps.
Related
I have a question about using JWT in a webapp: An auth-service provides a JWT which gives me the information whether the user is known or not. Then another service will be called to check the user roles based on the JWT. It appends an API-key, the user roles and will call the real API.
Now my question: What ist the best auth flow?
Should the webapp do only one call: Calling the JWT-service which proxies the request to the auth service and this service proxies it to the real backend and all the way back?
Or should it look like this: Webapp calls JWT-service. The JWT-service returns the JWT to the webapp and then the webapp will call the auth-service in a second request.
Unfortunately the JWT-service cannot check the userroles :(
Are there any advantages/disadvantages or BestPatterns?
I hope that is not too confusing:D
Best
Lukas
I think you should consider using an API Gateway between your frontend and the underlying microservices. That Gateway will take care of forwarding all the calls.
For example, it will call the auth-provider which will build the JWT.
This token, in turn, should contain all the relevant roles for the logged-in user, exposed as claims.
JWT validation doesn't necessarily require a service call.
I wrote a blog post a while ago explaining the flow more in details: https://www.davideguida.com/handling-authentication-and-authorization-in-microservices-part-2/
I'm new to microservice architecture. I was reading about it and start to be interested in developing website using the architecture. I've used Lumen micro framework.
What I am going to ask you has been browsed on the internet and I couldn't find the way. So, I finally reached out to stackoverflow. Below is the overview of my current implementation.
Up until this point, I am able to request user, patient, treatment, etc.. data from the api gateway and get the response data properly.
When client requests user data like name, department, client requests this route, http://localhost:8000/users/1, (port 8000 is for api gateway and 8001 for user service, let's say) and gateway goes to 8001 and grab the user data.
I've also enabled the authorization between api gateway and individual services in order to prevent separately perform CRUD operatons to the individual services - when request goes from gateway to service, I have put the pregenerated token (which is also predefined in the service) in the header and when it reaches the service, the service validates if the token is equal by comparing its predefined one. So, it's working.
But to be able to request from api gateway to services, I've used client credentials grant type. So, here is my question.
How can I implement the login and register? Does client credentials
grant type enable to do so? If not, what is the appropriate one? What
is the right way to implement the system? Could you please kindly explain in
advance? Thank you so much.
Updated
In conclusion, I want to know how to configure authentication between front-end and api gateway.
Your API architecture looks good - nothing there needs to change. However there are 3 parts to the architecture:
APIs (done)
UIs (to do)
Authorization Server (maybe use a free cloud one?)
As a next step maybe focus on login. My tutorial will help you to understand the interaction and what needs to be coded in UIs. Or if you prefer just view the message workflow.
Registering users can be a more complex topic and depends on the type of system. Happy to answer follow up questions if it helps.
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.