I found one interesting article that has this illustration:
It says that:
API Gateway verifies access token for all incoming requests via introspection
But what does this mean?
it says that gateway goes to authorization server and validates token (JWT).
why is that needed?
if gateway has authorization server's public key, it can check token validity using signature just like every backend service, why is introspection needed and how is it done?
Depending on your Identity provider it can be done either way but there are trade offs.
If you validate the token locally then yes it can use public keys to do that and that's very efficient way, however downside is that if the token or signing keys are revoked then your token is still valid. With Remote check you have to bear the http overhead but that is more reliable.
Normally tokens are kept short lived and validated locally. But if your access token are long lived, your application require strict access controls or library doesn't support local validation then it's a good idea to check them remotely
I believe you are looking at this document.
What I understood from this Secure API Gateway is that the gateway is responsible for introspection and the back-end services will only check the token signature, which is less secure than introspection, but still a layer of security.
Introspection is necessary to validate the token information against the Authorization Server.
This is more secure, because the system can ensure that the token received is not malicious, expired and it is from an known source.
The details on how it is done are explained in RFC 7662.
Yes, the gateway could validate the token signature if it has access to the certificate.
I can't really tell why they choose the back-end server to do it, probably a project decision.
API Gateway primarily meant for routing the incoming calls to the corresponding MicroService Clusters.
In addition to that,it can also play a role to validate the token, so that only valid traffic is routed to the downstream servers (filtering malicious traffic).
The level of validation could be up to the product owner/architect decision. It could be as simple as validating against the list of in memory cached token or in depth validation on set of claims, digital signature verification, expiry time, audience claim etc.
You can view the set of claims inside the token using JWT decoder like https://devtoolzone.com/decoder/jwt
Related
Does OAuth Client Credentials flow provide superior security compared to an API that exposes a custom authorization/access endpoint which produces a temporary access token used to perform requests against an API?
From my perspective:
Both expose the same data, namely an identifier and a secret and both submit data over a secured SSL connection. Both can receive an access token securely and both could be setup to revoke access tokens.
Short answer is, "no" but there is a broader consideration. The point of this flow is that it is coming from your own known server to the protected endpoint. It is a supported exception to user oauth security, in other words. But it allows the same overall protection scheme for the endpoint even if you are reducing from the full protections afforded by other flows. The point is that a custom authorization endpoint that mimics oauth for client credentials only is not a full authentication solution. However, if you will never have users and never need the other flows, then that is the important trade-off. In that case you are correct in your assessment, but you have added the risk of needing a broader range of flows in the future that you will then have to custom code.
First of all let’s clarify we are aware that OIDC and oAuth2 are different protocols, albeit OIDC builds on the flows and mechanisms defined by oAuth2, and they also use different tokens, a JWT Identity Token used for OIDC, and a resource access token (possibly also JWT formatted, but not required to) for oAuth2; the first deals with the issue of federated authentication and the second deals with the issue of federated resource access authorisation).
Having said that, for this specific question it is more or less irrelevant what type of token we do have, as here we are interested in understanding the mechanism through which a client system trusts the legitimacy of a token (please understand client system as defined by the oAuth2 flow definition of client system plus any extra system capable of accepting those same digitally signed tokens).
For the sake of simplifying the argumentation, let’s assume that we are following an auth code grant flow. In this flow after the end-user has been redirected toward the Id/auth server, provided his credentials successfully, and being redirected back to the original "issuer client"; we can be sure that this “issuer client” can trust this token because it was obtained through a backchannel http request which provided the access code plus a client secret unknown to anybody else, so for this "issuer-client" it is trivial to trust this token. Let’s call this the “trivial case”.
Now let’s assume we have more client systems capable of potentially accepting this previously generated token -as long as that token is valid of course- (this would indeed be a form of SSO, because those systems are basically “bypassing” their end user login, by virtue of trusting this token previously generated by ANOTHER client). The question I have is how can those other clients (which didn’t issue the token initially as described previously on the trivial case) trust the legitimacy of this token?.
One way to solve the point in the above’s paragraph, would be for clients when presented with a token, to “ask” the id/auth provider if it indeed generated the token; but in different documentation & blogs I’ve seen it seems it is often the case that client systems usually accept the token without talking back to the Id/auth provider. How does this happen that the token is on itself enough for establishing trust? It is mentioned that the digital signature ensures nobody changed the token, but how can those systems know the token wasn’t generated by other -potentially malign- Identity/auth server?. Let’s say that we have a 2nd Identity/authorisation server that issues tokens identical in structure to the ones of the 1st one; under this situation, how do clients know that a token comes from auth server 1 and not auth server 2? For the clients to discern with 100% certainty that a token not only wasn’t changed, but also that was generated by the authority the clients know and trust, it seems as if the tokens need to have as part of their digital signature some piece of information which is specific to the Id/auth server that generated it and can’t be replicated by any impostor (and the clients knows how to decode).
So that is the gist of my question, how can “non issuer-clients” (when presented with a token), know without speaking to the Id/auth provider, that the received token not only wasn’t changed (for this the signature), but also know from which Id/auth provider they come from, and also how is it prevented that a “fake Id/auth provider” could generate almost identical otherwise perfect tokens.
Thanks in advance for any feedback, and sorry for my limited english, it is a complex topic and probably the question isn't formulated in the best way.
The API's that receives the tokens usually queries the token providers /.well-known/openid-configuration endpoint to download the public signing keys.
then when the API receives an access token, it can use the public key from the provider that the API trusts, and verify that the access token is genuine and has not been modified.
Inside the token there is typically also an audience claim, that specifies who the intended target is for the token and also a claim describing who issued it.
So, there are many ways for a resource that receives an access token to verify that it is trustworthy.
I am developing an app using microservices in NodeJS. I have built an auth api which handles the usual registration login etc and it issues JWT's
How do I use these to protect routes in a separate API microservice written with Express?
Do I need to use JWT with the secret to decrypt the token in the API app?
You could write a library that you import into your other microservices that requires all routes by default to require authentication. This library could have a mechanism to validate JWT's at the microservice level, so you never need to talk to your auth api to see if a JWT is valid or not. See the description and diagram below:
Your auth server will will need to be the single issuer of JWTs to your microservices. So, when a user logs in and successfully authenticates, your auth server will issue a JWT signed with a private key (signing MUST be asymmetric - RS256 is one example) you keep on the auth server only; do not give this private key to other microservices that you wish to validate JWTs inside of. What you can do is derive a public key based on the private key you sign your tokens with and publish that to an endpoint on your auth server that requires no authentication - the public key will be represented in the form of a JWK (see link to spec). Google does something similar here. Then, in each of your microservices, your library will need to devise a way to make a GET request to the public key endpoint on your auth server every X minutes to see if there are any changes and cache the public key in each microservice. By having the public key cached in your microservice, you will be able to validate the requesting JWT inside the service that is being requested.
Then whenever a request comes into one of your microservices, the library you import will examine the requesting JWT, check its validity, and grant access/authorization if the token is valid. The beauty of using a private/public key pair and asymmetric key signing is that you can validate a token based on the public key alone, but not sign it. So as long as each service has the public key from your /cert endpoint, they can validate a token without ever needing to talk to the auth server or knowing the private key.
This will require a little more work up front, but will yield you massive amount of ease, flexibility, and peace of mind in the future knowing only one source knows your private key.
One common pattern here would be to use an API gateway as the entry point to your entire microservice architecture. Incoming requests for authentication would be routed to the appropriate microservice. If the credentials provided be correct, a new JWT would be returned to the gateway, which would then forward to the caller. For the actual microservice APIs which comprise your application, the gateway would check that the incoming JWT be valid before allowing the request to hit the microservice.
This answer leaves out a few things, for simplicity. For instance, often you would want to have an authorization microservice, which decides what a user is allowed to do. Also, implementing JWT can be involved. You might need a cache layer to keep track of whitelisted and/or blacklisted JWT.
Here is the solution I came up with, to handle user data we can implement an Identity Provider Service (IDP) which is responsible for signing JWTs with symmetrical keys (rs256) and storing user information. The Identity Provider also has an open endpoint which will expose the public key in the form of a JWK (JSON Web Key) which is used to sign the JWT, This endpoint can be used to validate issued keys by any other service (ideally the external service would cache the JWK to reduce traffic to the IDP).
But This also poses another issue, that is we will have to implement more code to validate the tokens with the JWK endpoint. This is where an API Gateway comes in, The API gateway sits between the frontend client and the API server acting as a checkpoint. The API Gateway caches the JWK using the IDP endpoint and validates all the incoming requests. This means we would only have to implement features like JWK validation, rate-limiting, and SSL only to the API Gateway and we will not have to rely on the internal services for implementing these. Plus another improvement to the API Gateway would be to write the decoded JWT data onto the headers so the API Gateway can pass the decoded data for example: x-jwt-email: person#email.com directly to the internal services.
I found inspiration for this implementation from various sources and this was one of the first system designs that have completed building so let me know if there are any loopholes or improvements that could be implemented.
The code for the above implementation can be found here:
Identity Provider
API Gateway
I want to design a web application which guarantees secure authentication and gives API access only to the authorised users. The basic idea is simply sending username and password to get the user authenticated. And user can make request to server with the session_id without authenticating himself again.
Definitely, it is very insecure. But as far as I could understand now, in order not to expose the user's credentials, we can apply TLS(https) to get it encrypted.
However, as I research around, I get acquainted with a lot of concepts, like Base64, HMAC_SHA1, API keys, OAuth1.0. But I could not understand why do we need those mechanism other than TLS. Can anyone help explain why TSL is not enough to ensure authentication and API access to be secure?
Secure sessions work fine if your web application authenticates the user, issues the session id and validates the id on each call. You can store the session id in a secure cookie that gets sent back on each request.
Things get more complicated when you have your API on a different domain. Now your cookies are not automatically sent to the service (same-origin policy). You could of course stick the session id in an Authorization header when you call your API. But now your API needs to talk to the same backend store maintaining your session state to verify the authorization. This backend store becomes a bottleneck in scalability and a single point of failure.
To get around this, modern protocols (like OAuth2) issue security tokens. These tokens are digitally signed (using HMAC) and the receiver trusts the token if the signature is validated successfully. No backend calls are needed to validate the token, just a simple cryptographic operation.
API keys are used to allow applications to get a security token without relying on a user to authenticate. Think of them as a password for an application.
Using security tokens also allows you to use a 3rd party authorization server (like Facebook or Google etc) and completely get out of the business of authenticating users, storing passwords, issuing tokens etc.
I would like to develop RESTful API for my web application. Client have to be clear JS + HTML and user have to somehow authenticate in system. I've read few articles about security and RESTful API but some point still are not clear for me. As I've understood at the first step user have to provide his credentials to server. After that server have to validate user credentials and if they are valid, sent some encoded token to user (assume it will be [user key]:[user IP]:[token creation time]). After user authentication client have to sent this this key with each API call. That's how I've understood RESTful API authentication principes.
With such solution I assume that token can be stolen and another user can access to secured user data (even if IP is included to access token and there will be validation on each request). For this purpose I plan to include token creation time but as I understand with such solution I have to renew access token each time when it expiring - in this case it's not clear for me how to implement "remember me" functionality.
It's not clear for me how to implement 100% safe authentication for my RESTful API. Maybe I'm missing something. Or maybe my understanding of authentication principes is wrong.
It depends from what authentication scenario you are using. For example when dealing with in ASP.NET MVC + REST with Basic Authentication it will produce for you token which is in the fact Base64 encoded string '{username}:{password}'. And you are right it could be stolen, that's why for Basic Auth HTTPS is must, as token goes throw Authentication header with Basic schema.
For REST security most suitable and secure are OpenId and OAuth. Just don't reinvent wheel and use already existing standards. OAuth in compare to OpenID includes not only authentication but authorization as well. OAuth already describes all nuances with token renew and token creation time and so on.
Now practical how to implement OAuth in REST. First of all read standard. For your case read with attention Implicit Grant flow, because standard has multiple flows for different client with different trust level and security.
https://www.rfc-editor.org/rfc/rfc6749
And after that you can try some already implemented library in technological stack you are using either Java or .NET. For client it is not so important to use library in compare but for server implementation
About potential security problem read here https://www.rfc-editor.org/rfc/rfc6749#section-10.
Some think that OAuth 2.0 is less secure that OAuth 1.0, and it is also dependant from token format. Anyway access token should be passed in HTTP Header and through HTTPS as well as clientid should be stored and passed securely.