I have a python grpc service that has API methods that need be aware of user information, such as username email address to do various filtering.
I have a python server-side grpc interceptor attached to the service that decodes the jwt (passed via the client's request context) for claims and verify the authenticity. The interceptor abort the call if the token is invalid and decode the list of claims from the token. But the thing is I need to be able to pass in the jwt claim information into my API methods so they can use that information to do filtering (and ideally I want to be able to attach the decoded username to the logs for all api calls in the interceptor).
It seems like, in the interceptor, I should be able to add the username claim decoded from the token to the context and pass it to the API method? But I have not found any documentation on how to modify the context.
My APIs do have access to the context with token and can decode for the claim themselves, but it seems weird to me add a decorator or method to decode the token to every API method definition.
The grpc/python team are interested in read/write ability. From what I can see, the repository maintainer replied on issue, and the examples at grpc/python only show how to read, not write. So for now, it look's like there's no way to manipulate this through python implementation. For server side, the only choice to manipulate the client's payload is to do something at the Servicer.
Related
I'm implementing a project with Supabase and Next.js where I would like to have the authenticated client make an API request to an endpoint. At that endpoint, I'd like to be able to get the user from the database.
My understanding is that on the client, I can call
supabase.auth.session().access_token
to get the JWT. I could include that token in my /api/ request, but how would I look up the user in the server-side function?
I tried using the service key and calling
supabase.auth.api.getUser('that token that I sent from the client')
but that doesn't seem to be the appropriate use.
Any help would be greatly appreciated!
(I don't want to use the client-side query with row-level security because I want to make external API calls from the server.)
We are using the KeyVaultClient library on an application in Service Fabric that calls a Key Vault to read various configuration data stored as secrets. The way the code authenticates to the vault is via an AAD principal with an SSL certificate. The code is creating a single request, but when we look at Key Vault logs, for every single request the code creates, the vault is hit twice. The first hit generates a 401 Unauthorized and then the second request is a Success.
It seems as if the library is possibly first attempting to hit the Key Vault without the credentials in our request before proceeding with the request we create. The second request works exactly as expected. This seems unnecessary. Has anyone had a similar experience?
This is expected behavior. Azure Keyvault has an authentication pattern which will always make at least one unauthenticated call to the vault. This is because some vaults have requirements that messages to them be encrypted with HSM protected keys. This information is returned in the authentication challenge from the first unauthenticated call.
For this reason each time you send a request to a vault you haven't connected to yet in that process, the sdk first sends the request with an empty body and without an Authorization header. This will result in a 401 which will have the authentication and message protocol information.
For more details, you could refer to the similar issue.
In my project I use the identity server 4, an SPA (Angular) and a protected API (PHP). I decided me to use the reference token. My Client (SPA) works with implicit flow (is it correct not to use a client secret?) And gets the access token after login (call the authorize endpoint). After that the SPA have to send the token to the API so the API can ask the identity server 4 (introspection endpoint), if the access token is correct and the API can get access to the user´s information.
Now I want to know, how to secure the communication. Because the access token has no information in it, is it necessary to send him with jwt to the API or is it enough with a normal JSON send? As I understand the API must call the introspection endpoint with jwt bearer.
Is this method secure or what else should I do?
There is no such requirement - the API to call the introspection with a JWT. If the API is set to work with JWT's it will just verify the signature of the token with the public key from IDS. If it is set to work with reference token - it will call the introspection, to get the user info (which is the payload of the JWT). Reference tokens documentation.
Your API needs to be protected with its ID and Secret, so that you can call the introspection endpoint.
When calling it you send the reference token (it is still an access token, but it is not a JWT), the client_id and the client_secret. The content-type of the request should be application/x-www-form-urlencoded and it should be POST.
The response from the introspection endpoint is the user info.
No need of additional security - the client ID and Secret are the security, and the call is made server-to-server from API to IDS (assuming you are behind https of course)
Let's take an example where we have an SPA accessing an API using the OIDC implicit flow.
Since OAuth scopes are coarse-grained, it is often necessary to perform additional authorization on the resource servers. This can be the case for example when accessing dynamic resources (e.g filesystem) via an endpoint - where access is restricted by permissions tied to the userId, but it is not practical to use OAuth scopes only because of the dynamic nature of the resources.
In these cases the endpoint itself can be protected by an OAuth scope, while access to the resources that the endpoint operates on (e.g files) will be granted based on the userId. Hence the user's identity must be securely sent in the API request.
An obivious choice can be to send the ID token that was obtained when authenticating, together with the access token that was obtained at the same time.
There is a standard way for sending the access token in a HTTP request (the Authorization header), but is there one for the ID token? Or should I just make up a header name like 'X-Identity'?
To answer the question: there is no standard for passing the ID token in an HTTP request.
But arguably there doesn't need to be one: in this case you may not need OpenID Connect since scopes are not the only information that can be associated with an OAuth 2.0 access token as you seem to suggest.
You can "associate" the userId with the access token so that the Resource Server can grant the Client access to the protected resource based on the identity of the user who granted the access token to the Client.
The "association" is implementation dependent: the access token can be a JWT that contains the userId claim or the access token can be an opaque value that the Resource Server can introspect/validate at the Authorization Server to obtain the information associated with it.
Instead of passing it in the header, you can pass it as a query parameter:
curl "https://resourcePath?auth=<ID_TOKEN>
Here's the reference:
https://firebase.google.com/docs/database/rest/auth#authenticate_with_an_access_token
We have planned to implement authentication in our API using OAUTH. For this purpose I read so many articles on web to explore it. After read these articles what I am understanding is
Send credentials to authorization server and after successful
authentication it will send you the access token.
Use this access token for further calling of your api methods.
To authenticate our api user needs to pass the following parameters.
Authorization Token
Employee ID
What I am thinking is to pass these values via request headers. Problem is that these request headers can easily be viewed in browser console and someone can misused it easily. Please suggest Is this the right way to authenticate api or we used something else for this purpose?