Firebase functions is caching non-existing Auth0 user access token - google-cloud-firestore

I'm currently using Firebase cloud functions as my mobile app's backend and I'm using Auth0 as my authentication provider.
My problem is that I've used Postman to send test login requests to my API and I'm able to get a valid JWT. I then deleted the user account through Auth0's user management panel and used Postman to test the login function again to see the type of response I would receive. Instead of receiving any errors, I receive a new valid JWT which allows me to access protected routes even though the user does not exist.
I've tried setting the response cache control to "no-store" and yet I'm able to receive a valid JWT. What could the reason be?

Related

How to save GitHub access token in single page application?

I created a single page application (SPA), which relies on GitHub API v4.
The API requires an access token to access, so I created an input element to ask users to store their access token.
I want to persist the entered token so that users don't re-input the token after reloading or re-visiting the site, without building any backend server.
I tried few things to achieve my purpose:
save the token in localStorage
It is very easy, but there are security concerns to store secret information in the storage, so I rejected this approach.
use GitHub OAuth App to fetch tokens
It is not suitable because it requires to store client secret in my app. Since my app is SPA, the stored secret can be read by any user.
use Auth0 to bypass the authentification
At first, it seemed very easy to get GitHub access token, but it requires a backend proxy server to fetch the token as described here
Is it impossible to persist the token without any backend server?
If so, how to persist the token easily? For now, I came up with the below solutions:
use AWS Lambda to encrypt the token and save it into cookie
When users input the token, the app send the token to a Lambda function, which encrypt the token and response it into cookie. When users back to my app, the app send cookie to the Lambda function and decrypt the token and send it back to the app.
use AWS Lambda as a proxy to communicate with Auth0
As described here, Lambda functions can retrieve the GitHub access token via Auth0.
However, I don't want to do this because I don't want to use two external services just to persist the token.

Api request to login/create/link user via Identity Provider

I need to be able to do the operations that keycloak do when using identity provider: login/logout/create account/link account, via api, not via html.
I am unable to find in your documentation how can i do these actions, all the documentation is based on html and a series of redirect, by using keycloak and its theme.
This is not compatible with a single page application, or ios/android native application.
Examples:
Get token and refresh token by using Identity Provider brokering (google/facebook), for existing/already linked accounts, when i already have the google/facebook token.
Required steps:
I get the google or facebook token, outside of keycloak.
I need to post this token into identity provider broker.
I need to receive from this response, the authorization and refresh tokens, just like i do a login with user/pass by using route ".../protocol/openid-connect/token"
Create a new account with the user received from Identity Provider, when i already have the google/facebook token.
Required steps:
I get the google or facebook token, outside of keycloak.
I need to post this token into identity provider broker.
I receive that there is no such user, and if i want to create the user.
I post that i want to create the new account.
I need to receive from this response, the authorization and refresh tokens, just like i do a login with user/pass by using route ".../protocol/openid-connect/token"
Link an existing account, with the google/facebook account received by Identity Provider.
Required steps:
I get the google or facebook token, outside of keycloak.
I need to post this token into identity provider broker.
I receive the information that the same account exist, and if i want to link the account.
I post that i want to link the account.
I need to receive from this response, the authorization and refresh tokens, just like i do a login with user/pass by using route ".../protocol/openid-connect/token"
I tried to do hacks and ajax calls, instead of html request, but in the end it does not resolve my problem, because i don't know what happened: it logged in? it created an account? it requires to link account?

REST API user and client authentication

I am building a REST API as the backend for a mobile app. I would like to check if the requests made to the API are coming from our mobile app. However, the API will require end users to login in order to access certain endpoints.
My questions is, how could I authenticate all incoming requests to make sure they are coming from our own app, while also authenticating the end users for some requests?
I was thinking of sending an API key with all requests in the Authentication HTTP Header to authenticate the mobile app, and (separated by a comma) also send along a JWT for authenticating the end-user. While this could work, it seems a bit "hacky".
What is the standard way of authenticating both the mobile app and the
end-user of the mobile app at the same time?
Using an application token and a user-specific session token is one method of separating authentication of the two. The application token would be unique for your application, and should be obfuscated so that inspection of the client's binary would not lead to easy detection of the token. The user-specific session token should be generated when the user is logged in. The client adds this user session key to future API calls, the server will check if the session key is valid, and can use it to look up any session state stored for the client.
However, optimally, you would implement the full oauth2 spec. as outlined in this ultimate guide to mobile API security:
Here’s how OAuth2 token authentication works from a user perspective
(OAuth2 calls this the password grant flow):
A user opens up your mobile app and is prompted for their username or email and password.
You send a POST request from your mobile app to your API service with the user’s username or email and password data included (OVER SSL!).
You validate the user credentials, and create an access token for the user that expires after a certain amount of time.
You store this access token on the mobile device, treating it like an API key which lets you access your API service.
Once the access token expires and no longer works, you re-prompt the user for their username or email and password.
What makes OAuth2 great for securing APIs is that it doesn’t require you to store API keys in an unsafe environment. Instead, it will generate access tokens that can be stored in an untrusted environment temporarily.
This is great because even if an attacker somehow manages to get a hold of your temporary access token, it will expire! This reduces damage potential (we’ll cover this in more depth in our next article).

How to set a authenticated user web session for sending rest requests

I want to test an API which has the followoing instruction:
This API requires the caller to have an authenticated user web session.
When I login to the application and send a GET request in other tab it works. But I want to send a PUT request now so I cannot use browser. How can I have an authenticated user session while sending request through some other rest client. For eg: postman/ mozilla rest client.
I have tried logging into application through chrome and then using postman rest client. But it did not work. I have also tried Basic authentication providing application username and password.
So, given you mentioned you're using JWT, your API is most likely handing out this token upon logging in. At this moment your web client (javascript?) is probably storing it somewhere (cookie, local storage, session storage… – you can use your browser's dev tools to inspect). For all subsequent requests, this token is attached. If this token is getting persisted as a cookie, the browser itself takes care of attaching it to every request. If it is persisted somewhere else, your client has to "manually" attach this token to every request.
If you want to test your API call, first you need to login and get your hands on the token. Then, for all authenticated requests, you need to attach this token (probably as the Authorization HTTP header).

Validate token in Azure mobile services with custom authentication

I'm trying to get Azure mobile services working with custom authentication. I came across this article:
Get started with custom authentication
and another thread with detailed explanation:
Implement Custom Authentication In Windows Azure Mobile Services.
My question is:
once the token is received after login, does it need to be validated manually similar to this thread ?
I've tried passing the token as Authorization header, but the ServiceUser is always null. (I'm using Fiddler for testing the endpoints)
You do not need to validate the token. Azure Mobile Services will do this for you. For example, it will automatically check if the token has expired, if it has been generated for your particular service (if it's been derived from your Master key), etc.
For example, if you have marked a method with [AuthorizeLevel(AuthorizationLevel.User)] and the token is not valid, AMS will automatically return error response (probably 401 Unauthorized HTTP response). So you do not have to worry about validating the tokens.
In order to use the provided token you have to add the X-ZUMO-AUTH header with the token as value to the request that you send to your service.