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.
Related
I am trying Firebase to authenticate users for a website that was initially built on Flask (using the flask login workflow with a postgres DB). However, I am not sure that I have a correct understanding of what would be considered best practices when using Firebase.
I read through this article, which I think has led me down a suboptimal path when it comes to actually managing users.
My questions are:
Should all the Firebase authentication be handled in the javascript?
If so, should I use the request.headers on the backend to verify the identity of the user?
Any tutorials (aside from the Firenotes one, which I am working through) much appreciated.
Should all the Firebase authentication be handled in the javascript?
No, it doesn't have to be JavaScript. But in general, you'll find that most apps using one of the existing Firebase Authentication providers handle the sign-in of the user in their client-side code, with calls to the authentication server.
If so, should I use the request.headers on the backend to verify the identity of the user?
When calling REST APIs Firebase itself passes the ID token of the authenticated user in the Authorization header, so that's a valid approach indeed. On the server you can then verify that the ID token is valid, and decide what data this user has access to.
I'm creating an app using firebase authentication and I'm still new to authentication and authorization. What I have already done is implement firebase authentication in the front end, when a user signs up successfully it will request to the backendend and verify its idToken firebase admin. When it's verified, the user's data will then be stored in the database together with the uid returned in verifying the idToken.
All is working but I have no clear idea on the best practices on authentication, am I on the right track? From what I've read, authenticated client should also pass a token in the header.
Should I return the uid to the client and use it in the header? If so, should the backend use it to check if there's a matching token in the database every client request?
I'm really quite lost with the log in flow standards, any answers are much appreciated thank you.
All right, so the first thing to understand is that Firebase operates on a client-side paradigm, meaning that you actually don't need to and should carefully consider whether you need to conduct Firebase operations server side. In principle, you can do everything on javascript on the web browser. or Android app. or iOS app.
If you do decide to move some functions server side, next best solution is to do them as hosted cloud functions in firebase too. See:
Callable cloud functions
If for some reason you need to deploy and host your own code, then you can continue as you are, doing auth client side, passing the token, decoding the token with node admin, and manually checking the user permissions as applicable.
I've been reading through a bunch of documentation for using OAuth with Azure AD, but am still completely confused about how to properly implement things for my situation. Hopefully someone can steer me in the right direction.
I have created an ASP.NET Web API application that uses the EWS Managed API to access Exchange on behalf of different users. My application exposes endpoints such as /Mailbox/Messages and /Appointments with the intent that some front end web application will eventually use them to retrieve a user's emails and appointments. Currently the endpoints are working using basic http authentication, but I'd like to update them to use OAuth. The application has been registered in my Azure AD instance and I've configured it to require the "Access mailboxes as the signed-in user via Exchange Web Services" API permission.
Since the front end hasn't been implemented yet, I've been trying to test by manually calling the authentication endpoint. This prompts me to log in and provide consent. If I consent, I'm redirected to the callback URL that I provided when I registered the app with the authorization code contained in the query parameters. I'm still not quite sure how I'm supposed to be using this callback, but for the sake of testing I currently have the callback redeem the authorization code for an access token. This is done by calling the AcquireTokenByAuthorizationCode method on an instance of the AuthenticationContext class and providing my application's id and secret. Again, just for the sake of testing I return the access token to the browser. I can then call my aforementioned endpoints (after some modifications) with this access token and get the emails for the user. I'm guessing much of this is not the correct way to be doing things.
Some of my points of confusion:
What should the callback that I registered in Azure AD actually be doing when it gets the authorization code? Is this intended for a different type of application? Perhaps one that isn't just playing the role of a middle man.
I'm trying to make my application somewhat RESTful, so I don't want to have to maintain the access tokens on my end between requests. As such, does it make sense for my endpoints to expect that the access token be provided in the authentication header for each request? If so, does that mean the front end application should be responsible acquiring the access token and passing it to me?
Being completely new to OAuth and Azure, I'm not sure if any other details are pertinent, but I can provide more information as needed.
What you are implementing is this scenario: https://learn.microsoft.com/en-us/azure/active-directory/active-directory-authentication-scenarios#daemon-or-server-application-to-web-api
Here's how it works:
Your client app redirects the user to sign in at the authorization endpoint
Your client app gets back an authorization code (if using the auth code grant flow, there are others)
The client app exchanges the code for an access token for your API app
It will need to provide its client id and secret along with the code and the API's resource URI to get it
The client app calls to your API app, passing the access token in the Authorization header
Your API app then validates the access token, and requests for another access token from Azure AD for the Exchange API
It will pass the access token sent by the client app, along with its client id and secret and the Exchange API's resource URI to Azure AD
Your API app receives an access token so you can call to the Exchange API as the user
And to answer your two questions:
Authorization code flow is not used with APIs, only with apps that have a user signing in, thus the redirect URL is basically never used
Your API can and must expect and authenticate the access token for it to be in every request. But the access token it uses to call the Exchange API can and should be cached on the API's side. This is provided out-of-the-box with ADAL, though the tokens are only in memory.
I have an admin-console for an existing service that I want to provide access to by adding login, using our company's OAuth 2.0 service. I want to use Apigee here, so that the web-app with the admin-console does not have to implement the login-logic.
My idea was to use AuthorizationCode flow and let Apigee manage the tokens and I looked into https://github.com/apigee/api-platform-samples/tree/master/sample-proxies/oauth-login-app, but I really can't see how our existing OAuth service fits in.
Is there a sample like that? Perhaps using Google's or Facebook's OAuth service to authenticate the user?
First, Apigee needs to be a proxy into the admin-console. This means that all traffic to the admin-console has to go through Apigee. Otherwise, you won't be able to enforce authentication.
Second, there are a couple different options for integrating with the external oauth 2.0 service. Apigee has the ability to store an external access token and use it as its own, or Apigee can generate a token and store the external access token as a custom attribute.
High level thoughts on how the Apigee proxy could look like:
ProxyEndpoint - endpoint exposed to clients connecting to admin console
TargetEndpoint (not shown in that oauth login-app example) - endpoint for the actual admin console
The flows that execute in the Apigee proxy before sending the request to admin-console will need to implement logic that checks an authentication token. If it's valid, let the request pass onto the TargetEndpoint (admin-console). If the request isn't valid, step through logic that goes calls the external oauth 2.0 server's auth code flow. This will require the following:
Apigee needs to be registered with external oauth 2.0 server.
Logic needs to be built in this proxy to support the redirection based flow of authorization code grant_type (obtaining auth code, receiving the auth code, obtaining token --> all while being redirection based and transparent to user).
In addition to #2, Apigee will need to store the external token as custom attribute and expose the apigee token, or store the external token for verification purposes later on. http://apigee.com/docs/api-services/content/authorize-requests-using-oauth-20 (see Delegating token management). After the token is stored, you'd need to respond with another 302 redirect to the initial uri + token so the request can pass through to admin-console as an authenticated request.
#2 isn't exactly straight-forward and there won't be an example proxy that shows this implementation. If the oauth 2.0 service supported a password grant, it may simplify the implementation, but allows the credentials to pass through apigee and not directly with the authorization server.
"Authentication requests to Firebase Simple Login are only permitted from domains you specify." and the two default domains are "localhost" and "127.0.0.1".
Let's say that my server's IP is "267.156.423.22". How do I setup my security rules so that that the two first domains can read specific data, but only the server can write it?
For example, if a client purchases a product, this fact and associated data needs to be noted on the client's account in the Firebase. For obvious security reasons this information must be 'writeable' by the server only.
The authorized domains configuration for Firebase Simple Login applies solely to OAuth-based authentication providers (Facebook, Twitter, and GitHub), and restricts requests to those origins in the browser.
That means if you're using one of those OAuth-based authentication providers, you'd want to enter in any origins which your end users will use to access the page (i.e. if your user accesses the page via subdomain.example.com, that'd the be origin to enter).
Keep in mind that Firebase Simple Login is built on top of that standard, one-size-fits-all custom login / token generation in Firebase. It is an abstraction layer intended to make it easy to generate Firebase Auth. Tokens, a secure way of sharing data between you and Firebase.
Once a token has been generated (via Simple or Custom login), you can begin using that token's payload in your security rules (via the auth variable). If you'd want your server to bypass security rules, simple generate a token with the admin privilege, or your Firebase secret. See https://www.firebase.com/docs/security/security-rules.html for more details.