My question is more about logical understanding than in my code itself (at the moment).
I created an API with Symfony and thanks to the tutorial on KahereCode.
I have now 2 possible clients, an application and a website.
I have some resources that must be public, for example the creation of user implies that my POST point of USER is public.
Currently, I have JWT Authentication bundle that returns a JWT token for the endpoints I have set as private.
This allows to identify the user and to limit the data to his own.
Only, isn't it possible to add an API Key in addition to this in order to identify my 2 clients and to limit the access to public resources to these two?
I would like to avoid, by leaving the endpoints completely public and vulnerable, that someone could launch a script to send data to a public POST endpoint that would overload the API, and even create unwanted users. (Well, I could still manage that with an email verification).
Can anyone help me understand how to set this up or point me to an alternative to what I'm presenting here?
Related
I'm extremely confused on how to use a centralized IDP with both authentication and authorization. The architecture for my project was to be a single web API and one React client. I wanted to keep things structured out into microservices just to try something more modern, but I'm having major issues with the centralized identity, as many others have.
My goal is fairly simple. User logs in, selects a tenant from a list of tenants that they have access to, and then they are redirected to the client with roles and a "tid" or tenant id claim which is just the GUID of the selected company.
The Microsoft prescribed way to add identity in my scenario is IdentityServer, so I started with that. Everything was smooth sailing until I discovered the inner workings of the tokens. While some others have issues adding permissions, the authorization logic in my application is very simple and roles would suffice. While I would initially be fine with roles refreshing naturally via expiration, they must immediately update whenever my users select a different tenant to "log in" to. However, the problem is that I cannot refresh these claims when the user changes tenants without logging out. Essentially, I tried mixing authorization with authentication and hit a wall.
It seems like I have two options:
Obtain the authorization information from a separate provider, or even an endpoint on the identity server itself, like /user-info but for authorization information. This ends up adding a huge overhead, but the actual boilerplate for the server and for the client is minimal. This is similar to how the OSS version of PolicyServer does it, although I do not know how their paid implementation is. My main problem here is that both the client and resource (API) will need this information. How could I avoid N requests per interaction (where N is the number of resources/clients)?
Implement some sort of custom state and keep a store of users who need their JWTs refreshed. Check these and return some custom response to the caller, which then uses custom js client code to refresh the token on this response. This is a huge theory and, even if it is plausible, still introduces state and kind of invalidates the point of JWTs while requiring a large amount of custom code.
So, I apologize for the long post but this is really irking me. I do not NEED to use IdentityServer or JWTs, but I would like to at least have a React front-end. What options do I have for up-to-date tenancy selection and roles? Right when I was willing to give in and implement an authorization endpoint that returns fresh data, I realized I'd be calling it both at the API and client every request. Even with cached data, that's a lot of overhead just in pure http calls. Is there some alternative solution that would work here? Could I honestly just use a cookie with authorization information that is secure and updated only when necessary?
It becomes confusing when you want to use IdentityServer as-is for user authorization. Keep concerns seperated.
As commented by Dominick Baier:
Yes – we recommend to use IdentityServer for end-user authentication,
federation and API access control.
PolicyServer is our recommendation for user authorization.
Option 1 seems the recommended option. So if you decide to go for option 1:
The OSS version of the PolicyServer will suffice for handling the requests. But instead of using a json config file:
// this sets up the PolicyServer client library and policy provider
// - configuration is loaded from appsettings.json
services.AddPolicyServerClient(Configuration.GetSection("Policy"))
.AddAuthorizationPermissionPolicies();
get the information from an endpoint. Add caching to improve performance.
In order to allow centralized access, you can either create a seperate policy server or extend IdentityServer with user authorization endpoints. Use extension grants to access the user authorization endpoints, because you may want to distinguish between client and api.
The json configuration is local. The new endpoint will need it's own data store where it can read the user claims. In order to allow centralized information, add information about where the permissions can be used. Personally I use the scope to model the permissions, because both client and api know the scope.
Final step is to add admin UI or endpoints to maintain the user authorization.
I ended up using remote gRPC calls for the authorization. You can see more at https://github.com/Perustaja/PermissionServerDemo
I don't like to accept my own answer here but I think my solution and thoughts on it in the repository will be good for anyone thinking about possible solutions to handing stale JWT authorization information.
My service allow any HTML documents to be converted to PDF using a POST request.
It is mostly used on the backend of my client's server and thus, the API key used for the communication is kept private.
Now, I'm thinking of a way to let my client's visitors be able to call my service on behalf of my client API key, without exposing this secure API Key.
My main issue here is security. If my client add an XHR POST requests that contains the API key, someone can take that API key and use it for their own purpose and abusing my client's account.
I could filter by domain, but this is easily spoofed so it's not possible.
I was wondering if there was a way to call a private service and be identified without risking its identity to be stolen, from the client ('s client) side?
If you're providing this sublet for authenticated users, then it's fairly trivial to give them unique keys (something that hashes their user ID or session against the API key and an initial timestamp, and checks it / logs it / looks for brutes before accessing the API). If you're doing it on the open web, without any kind of user authentication, then rate limiting gets very tricky indeed. Generally you'd want to use a combination of session hashes, IP address, operating system and browser data to create an anonymous profile that gets a temporary key on the frontend. One fairly solid way to do this is to force users through a CAPTCHA before serving a temporary key that allows them a limited number of uses of the permanent key. Any user whose ip/browser/session matches the existing attributes of a known client key is shunted to that one (and gets to skip the CAPTCHA); anyone who doesn't match an existing profile gets the CAPTCHA. That makes you a less attractive target for spoofing. On top of that, you should always rate-limit the entire thing, within a reasonable number of hits per day based on what kind of traffic you expect (or can afford), just so you don't have any surprises. This is the minimal security you'd want if your client's money is on the line every time their API key is used. It will require a simple database to store these "profiles", track usage, check for brutes and maintain the currently valid client keys. Client keys should always be expired regularly - either with a time diff against when they were created, or a regular cron process, or a maximum number of uses, etc.
One other thing I frequently do is rate-limit based on a curve. If I think 5 uses per minute is reasonable, for example, then after 5 uses in a minute from a session, each usage adds a delay of a fraction of a second * the number of uses in the last minute, squared, before the data is served.
The best answer would be to put this all behind a login system and secure that.
Assuming that you are using OAuth kind of system, In that case, make use of Access Token Mechanism that provides access to private API/User's data on behalf of User(Client) without exposing his/her credentials or API Key(Authentication key), also the access token can be expired based on the time/usage.
Example: The access token is generated against a single endpoint that can be the Html Conversion endpoint and will be expired once the action completion.
https://auth0.com/docs/tokens/access-token
And following blog post would be helpful to architect your authentication system
https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/
there is no good way to do front-end secure storage but my recommendation is :
is an API that used HMAC signing of requests in combination with OAuth authentication. The API key is actually a signing key. they key does not get transferred. The API key can still get found on the front-end but it becomes useless because you still need the OAuth token to send a valid request.
i know users will have to login in, but you can see this as an advantage because atleast you can log who is using the app by getting information from oauth.
please consider back-end secure storage!
You can use JWT tokens in my opinion. On the basis of username, password or any other info you can generate unique jwt tokens for different users.
Anyone can decipher these jwt tokens but not he unique security token.
If you want to add more more security to tokens, use JWE, encrypted web tokens.
More about these schemes can be found at https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-b63310d201a3
Hashing is a decent option and should be done anyway, but for a fully secure method that wouldn't add too much complexity, you could simply abstract away from the authorization/API key by building your own API to interface with the API. This way you could both limit the kinds of things that can be done with the API key and also completely obscure the API key from the user
I don't think you should always go for user auth or JWT, it just doesn't fit all use cases. The idea of using a Captcha is interesting but also somewhat complex.
If complexity is not an issue I would rather use an infrastructure approach, I'm most familiar with AWS so I'll focus on that. Assuming you can change the host of your front end you can have your site hosted on an S3 bucket, served through a CDN, and create a proxy Lambda function that will hold the logic to call your API and store the API key as an encrypted environment variable. This Lambda you call through an API Gateway that can only be called by a specific IAM role which the S3 bucket also uses. You can also use a Cognito User Pool without authentication.
Going back to a simpler alternative the Captcha approach can be implemented as an attestation provider. I know of two services that do this, Firebase and KOR Connect. Due to Firebase using this approach only for their own resources as of the time of this writing I much rather use KOR Connect as it’s a very simple middleware that basically solves this issue. I won't go into detail about these services as it’s not the main concern of this topic but you can check the documentation their respective links.
First of all i wanna apoligise for my bad english, iam from holland.
For an school internship i read the last days a lot about API's and watched a lot of video's. But the security options are not clear for me. I read somethin about Oauth, saml and openID but i dont know which i can use in my situation.
This is the situation i will create. i need to add 2 security's. one for the private(internal) side and one for the public side.
Private(internal) side
For the private side i cant find any solution. I think i can use oauth for it . but i cant find which flows there are and also webflow) dont know which flow i need to use. This one is what i mean (youtube) i also read topics on stackoverflow but i cant find a clear answer on this question.
The backend on the private side wil never change and there wil never be more api gateways or backends on the private side. No-one need to be acces to the backend, only the API gateway.
Public side
On the public side there are a lot kinds of clients but they dont need to login with credentials. I only wanna know which application uses our API and how many connections they make. I will be able to disable the acces from one client. Also here i came out by oauth. but the flow i found works witch user credentials but i don't need to identify each infividualy user.
Can some help me to find a good or best practice security method for my situation?
You don't have to care about OAuth. It is enough to (1) issue a pair of API key and API secret (= API credentials) to each client application and (2) require that API calls to your Web APIs come along with API credentials.
OAuth is required only when your web service has end-users and you want to allow third-party client applications to access the end-users' data with restricted privileges.
I have developed a REST/JSON API. The API exposes a lot of features. The API will be consumed by applications we design internally (mobile apps and web apps), by applications designed by our resellers and by applications designed by businesses. I am looking at securing the application by implementing authentication and authorization. I have 'googled' a lot but my research has left me with more questions than answers.
Our internal application will be used by end users registered on the application. In essence, our application is just a client taking request from the end user, taking it to the REST API and retrieving the data for the end user. Our internal application should be able to perform all the operations exposed by the REST API. What is the best way to handle user login on our internal application? HTTP Basic over SSL or OAuth?
Our reseller applications can create users like they own the users but ultimately the user details get stored in our database. The reseller application will just act as a client taking request from the user and fetching user data. Our resellers applications should only be restricted to some operations of the REST API. What security mechanism will I use to implement this kind of authorization and user login?
I hope my question is clear. Thanks for the help.
From what I understood in reading this there are two parts to your question:
What is the best authentication method for my API?
I recently developed an authentication system for an API that was modelled on OAuth but didn't have every single one of their specifications. The system was basically the same as what Amazon use for their API. [This article]1 is very helpful if you want a secure API authentication model without having to use OAuth.
The model uses these principles:
Authentication data will be passed with every request to the API server
Requests will include a Unix timestamp from when it was generated
The entire request (including the timestamp) will have an HMAC hash generated and sent alongside the rest of the data. The hash is generated using a private key that only the API server and the API client know.
The API takes the data (including the timestamp), generates an HMAC hash using the private key for that user (identified by a user ID, user name, public API key, whatever) and compares it to the hash sent with the request. If this was successful, regular authentication proceeds and the request is processed. Note: the API will check the timestamp and compare it to its own to make sure the request has occured within a valid timeframe of, for example, 30 seconds, 5 minutes, 10 minutes, etc.
Of course, you can use regular HTTP authentication over SSL/HTTPS also, but I find this way to be very good because you achieve a high level of security without needing to implement every aspect of the OAuth protocol.
How you authenticate is up to you essentially. I prefer to go with methods employed by large, trustworthy organisations (such as Amazon). I personally didn't want to go the whole hog with OAuth like Twitter, Facebook etc.
How should I allow different users to access different endpoints in my API?
You should have an internal map in your API server which contains records allowing or denying specific API accounts from accessing certain endpoints. In my API server I decided that all endpoints would be "allow" by default, and I would specify which accounts would not be able to access certain endpoints.
You could also set up different groups or types of API access accounts which could have group permissions like this.
My suggestion would be to [read this article]2 twice, or three times, then read it again. Then, implement the methods suggested within.
Personally, I think the best method for ensuring as much security as possible is to restrict absolutely everything in regards to the request to be within a set of boundaries that you define, e.g. I want this endpoint to only be accessible by GET HTTP requests (all other HTTP methods will throw an error), up to 3 times daily per account, within a 30 second timeframe of request to server, only allow a narrow range of data to be returned, etc.
Limiting the HTTP method is very important to reduce the risk of your API doing things it shouldn't, especially with a RESTful API as endpoints can be used to do multiple things depending on the request method. You can even set your permissions for each API account to restrict certain methods on each endpoint, e.g. API user xxx can GET information from an endpoint but cannot POST, PUT, PATCH etc, or API user xxx2 can POST data but cannot GET any, etc.
[EDIT] 1 and 2: www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ (not completely removing the link but keeping the url unlinked as it no longer works/redirects to random sites)
I'm building some RESTful API for my project based on Play Framework 2.X.
My focus is on the authentication mechanism that I implemented.
Currently, I make use of SecureSocial.
The workflow is:
An anonymous user calls a secured API
Server grabs any cookie Id (kind of authentication token) and checks for matching in the Play 2 cache. (cache contains an association between cookie Id (randomly generated) and the user Id, accessible from database.
If any matched, user is authorized to process its expected service.
If none matched, user is redirected to a login page, and when filled with valid credentials (email/password), server stores its corresponding authentication data on Play 2 cache, and sends the newly created Cookie containing only a custom Id (authentication token) to user and of course, secured through SSL.
While the cookie/token doesn't expire, the user can call secured api (of course, if authorized)
The whole works great.
However, after some search, I came across this post, and ...I wonder if I'm in the right way.
Indeed, dealing with cookies ("sessions" in Play's term), would break the rule Restfulness.
Because an api really considered as stateless should be called with ALL the needed data at once (credentials/tokens etc..). The solution I implemented needs both calls: one to authenticate, the other to call the secured API.
I want to make things well, and I wonder some things:
What about the use of Api keys? Should I implement a solution using them instead of this SecureSocial workflow? Api Keys would be sent at EVERY API CALL, in order to keep restfulness.
I think about it since I want my APIs to be reached by some webapps, mobiles and other kind of clients. None of all are forced to manage cookies.
What about OAuth? Should I really need it? Would it replace totally the usage of simple api keys? Always with this objective of several clients, this known protocol would be a great way to manage authentication and authorization.
In one word, should I implement another mechanism in order to be Restful compliant?
this is quite an old Q, but still worth answering as it may interest others.
REST does mandate statelessness, but authorization is a common exception when implementing.
The solution you described requires a single authorization process, followed by numerous service calls based on authorized cookie. This is analog to api keys or OAuth. There's nothing wrong with cookies as long as the service isn't of high-security nature and that you expire then after a reasonable time.
Integrating OAuth into your service sounds a bit of an overkill and is recommended only if you expose the API to 3rd parties (outside your organization).