Is it supposed to be possible to generate your own JWT within the negotiate function for SignalR Serverless AND have that same JWT passed back to you when the connection event from EventGrid is triggered?
When my EventGridTrigger executes upon a new connection, I get given the UserId which I set, but the AccessToken isn't the one I returned from the negotiate function.
I'm wanting to store extra info in the JWT that can later be accessed when the Serverless SignalR Client Connection Connected event fires, by way of additional claims in the JWT.
UPDATE: While the below is true, based on the discussion in this issue, the custom token is not passed to Event Grid. Instead, the recommendation is to use the new upstream feature.
This seems to be implemented in the SignalR Service Extension for Azure Functions. You could try a similar approach.
If you are using Azure Functions, the SignalRConnectionInfoAttribute has properties for the IdToken and ClaimTypeList required for this.
Related
I have two components:
mydomain runs a nextjs along with next-auth.js
api.mydomain runs a back-end API that mydomain's client points to make some request
Mydomain is authenticated via the Next.js's Github provider, and as long as I get next-auth.js creates a JWT session which is sent to the client as a form of a cookie (correct me if I'm wrong). Then, if you need some info about your authentication, you can use the hook useSession on front side in order to access your JWT session.
My frontend is not using the api nextjs' functionality though: it communicates with an API through axios HTTP calls, which is deployed separately. What I would like to do is passing the Nextjs' JWT to my backend in order to verify authentication and authorization, but I'm not sure if it's possible, safe and recommended.
So: how could I accomplish that? The only alternative I see is generating a separated JWT token within the JWT callback, pass back to the front and use it for my calls, but I see it like a redundant thing actually, like embedding a JWT within a JWT.
Here is what I'd like to do in summary:
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.)
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.
I am developing a dialogflow agent with its fulfillment webhook in firebase functions(using Actions on Google Client Library). How can I secure it to let only my agent has access to these functions?
I read the following document, but it didn't provide any further details on their implementation.
https://dialogflow.com/docs/fulfillment/configure#authentication
It's important to secure your webhook to prevent unwanted, potentially malicious calls. Dialogflow supports two mechanisms for authentication:
Basic authentication with login and password.
Authentication with additional authentication headers.
Dialogflow provides these two ways to be somewhat flexible in how you secure your webhook.
If you're using a load balancer, and API gateway, or have a firewall in front of your webhook - you may be able to have that system block requests to your webhook path if they don't have a particular header set to a particular value or if they are making requests using Basic auth that doesn't have a a valid account in the system.
If you're not using something like that, or it is too difficult to configure, you may use these tools to filter things out when the function itself is called. If you're using the actions-on-google library, you can set the verification parameter when you create your dialogflow object to enforce matching the auth or headers and, if they don't match, to reject the request.
I'm struggling to decide how best to add authentication and authorisation to my SignalR service.
At the moment it is hosted in Owin alongside a WebApi2 web service. I use OAuth2 bearer tokens to authenticate with those, and it works perfectly. However, I wonder if they're suitable for SignalR?
My client is JavaScript based, and SignalR uses WebSockets if available. This means I can't use the Authorization header. I figured out that I can supply the token using the qs property before I connect. But of course an OAuth2 access token will expire (and relatively shortly in my implementation). I assume that updating the qs property won't make a difference once connected (particularly with web sockets).
I suppose my question is what is the best way to supply a security token, ticket, or any kind of authorization information to SignalR? Preferably a way that can be consistent on both my WebApi and SignalR, but I am looking to know how I should be doing it.
Thanks
It's been sometime now - but we used to look for the auth cookie in the signalR request to ensure that only a signed in user can subscribe to signalr notifications.
It didn't handle the case where the token expired - since the cookie was checked only on connect. This wasn't a problem for us.