I'd like to send an csrf protection token with every cloud endpoints request, but I don't want to have to specify this every time I call one of my services. How would I implement a sort of proxy, that inserts this token into any call my application makes?
Related
What would be the recommended way (simple, and secure) to initialize CSRF token when working with Single Page Applications?
I have figured out some possible solutions but all of them have some downsides:
a) Before login or any request, create CSRF request to obtain a token.
Downside: The Client/frontend should implement logic to request CSRF if it is missing
b) Exempt login request from CSRF protection and initialize token on every login
Downside: Is it safe to exempt login from CSRF protection?
If using multiple endpoints and Single Sing On, we still need to init CSRF token in every endpoint
c) Init CSRF token when the client request a frontend code (on SPA load / refresh)
Downside: Complex logic and extra request to backend needed in frontend providing endpoint
If we use multiple endpoints and can not validate the same CSRF tokens in every endpoint we do not know where to init the token
The current solution/answer to this problem is the following:
Client sends a CSRF token request
Server adds CSRF token into client cookies
Client sends a login request with his credentials and copies the CSRF token from cookies into headers
Server checks the cookie & header match and processes a login request. The server sets a session cookie and rotates a CSRF token.
Other (login required) endpoints check header & cookie match AND validate session cookie.
When working with multiple endpoints
Implement BFF or proxy server which handles the CSRF protection. Allow connections to the server endpoints only from the proxy/BFF server. The endpoints does not need CSRF protection anymore.
All requests from Client / browser is routed through the CSRF protected BFF/proxy server.
Pros
Login requests are now protected with CSRF
If multiple endpoints are needed, only one CSRF token init request must be done.
CSRF token is rotated and unique in every new session.
Cons
Client/frontend should implement CSRF request logic and missing CSRF token error handling thus increasing the complexity. CSRF token init can not be done silently for example during the login request.
When working with multiple endpoints, separate BFF/proxy server is needed.
I am building an application that spans over several parts of infrastructure.
An end-user can sign in to a portal using OAuth 2.0 authorization code flow. When calling different APIs, the portal requests tokens on-behalf-of the signed in user and attaches those to outgoing requests. The tokens received to call external APIs have an aud claim matching the target API.
When a call to an external API is fired, it first passes through an API Gateway. This API Gateway validates the token and ensures the aud claim is actually intended for this endpoint. It also verifies roles and a few other claims.
When the gateway checks pass, the request is forwarded to the actual implementation. Now the actual implementation also verifies the token, but only that the token is valid (e.g. not looking at specific claims). That is not to say that the claims aren't used internally in the application after the token is validated, roles are very much part of the application logic.
So to summarize this as bullet points:
User signs in to portal
User performs some action that causes an API call
Portal attaches token to outgoing request
Request hits gateway for 1..n claims are validated
Request is forwarded to actual implementation
Implementation again validates token is valid, not looking at claims
All endpoints are public, e.g. I could call any of these from anywhere as long as I have a token.
In the above outlined scenario, I'm handling the token properly?
In general, what is the recommendation for tokens passing through several layers of an application? Should every layer validate the token? If yes, are there exceptions to the rule?
Typically, JWT tokens are validated when are sent from the client-side to the server-side. As these tokens are signed, if anyone tries to tamper with the token before sending it to the server-side endpoint, the token verification will fail, therefore these tokens are a secure way of sending the session of an authenticated user to an API or a server endpoint.
These JWTs can be also transferred between servers or different application layers, and it always would be a good practice to verify the token before processing it. It is adding a layer of security to avoid anyone sending tokens to that layer directly and skipping the validation.
I have 3 services (in the real much more):
Authorization service (uses OAuth 2.0)
Frontend service
Resource service
and client (web-browser).
I store session_id, access_token and refersh_token in cookies of the user's web-browser. The user goes to Auth service, signs in and gets these tokens. After his web-browser is redirected to Frontend.
Frontend and Resource services can't validate tokens because they know a nothing about it, so they must make a request to Auth service.
The current scenarios:
The user (web-browser) sends a request to Frontend service, the Frontend sends a request to Auth service to validate access_token. If it's invalid the Frontend sends a request to refresh token using refresh_token.
If the Frontend needs an access to Resource service to process a request then the Frontend sends its client_id and access_token to Resource service. The Resource service sends a request to the Auth service to validate an access_token too.
Are my thoughts right? Or it has simpler schema?
P.S. All services use RESTful architecture.
OAuth talks about how the tokens be exchanged. What you have mentioned it seem liek you are talking about using implicit grant, which is little less secure and you may think of opting for authorisation flow.
Other than that, in microservices when you have many services and one user request pass through many downstream services, verifying the token with auth provider at each and every step might become a bottleneck.
There are ways out there by which you can skip this call to auth server and still validate the sanctity of the token without making an explicit call.
One way is to make use of JWT. These tokens are signed by the Auth provider and your services have keys which can help you validate if the token is modified on it way, and token itself has all the information you need to ensure validity of it, like expiry time, intended audience, clients, roles etc.
On login you get AT and RT. AT could be passed along to downstream for authentication and authorization and RT could be used when AT is expired.
You only need to talk to auth provider at the time of login and when you need to refresh the token.
You can read more about the JWT OAuth2.0 with JWT and OIDC to get more information around it
I have Oauth2 implemented in my application to protect API calls.
My Oauth and resource server are on two separate physical boxes(but on same network). For each call on resource server it needs to call Oauth server for Oauthtoken validation.
I have millions of request coming to my resource server in a day.
Currently to validate Oauth token I am using rest call from resource Server to Oauth Server.
Is there a way to make this faster as each and every call needs to be redirected to Oauth server? Can webSockets solve this problem?
If you don't need to revoke individual access tokens, you can use stateless (JSON Web Token) JWT tokens. JWTs don't need to be validated on the authorization server. As long as the JWT token is signed by the authorization server (asymmetric cryptography), you can validate the token on the resource server itself using the authorization server's public key.
This makes for fast authorization (since it skips a server-to-server round trip) at the cost of easy revocability.
Note: you can also use a shared secret (symmetric cryptography) but then you need to make sure all the interested parties have the shared secret (and keep it secret).
Look into spring-security-jwt and https://jwt.io/
I am building a RESTful web service using ASP.NET web API. I've read that it isn't very RESTful to use session authentication since a "login" request is required before any other request can be successfully made. In addition, it requires the client to maintain state.
My original design was to have the client call a "login" request using basic HTTP authentication over SSL. The web service would then verify the credentials and respond with a session key. The client then uses that session key to sign all subsequent requests. When the web service receives any of these requests it looks up the session key, signs the request in the same way, and checks if the two signatures are equal.
Is it possible to avoid this session authentication without having to send the username/password with each request? The credential verification does not happen within the web service (it is routed to another server that maintains users). I'm concerned that performance will be affected if I need to validate each request.
It's not possible. You either store the state or get the credentials with each request. The second option is what you would want with your HTTP API.
Depends what you mean with "validate"
you could e.g. cache the hash(username+password) in your application. And on subsequest requests check if the cached entry still exists. This way you can save roundtrips to your backend store.