As far as I know firebase Otp verification works on the following way.
1)On each platforms firebase provides a custom UI for sending and reading OTP.
2)After successful Otp verification firebase returns user data along with a token.
My question is there any way to check that token is valid or not .
I can't find anything about the token verification API from their documentation.
After phone number authentication you get a Firebase ID token like you do for all other firebase authentication methods. You can get it by calling firebase.auth().currentUser.getIdToken().
To verify it on your own server, you can send it to your server along with authenticated requests and use the Firebase admin SDK verifyIdToken to verify that ID token and parse its underlying claims.
Related
I am attempting to use firebase on my server for authentication and to provide an authentication experience for users that does not require pulling in firebase client side (for the moment).
A /login endpoint receives a username and password. Using firebase.auth().signInWithEmailAndPassword, I am then returning the JWT token to the user. They can then use that in subsequent requests to my RESTful API as the bearer token.
The problem I'm struggling with is when that token expires (after an hour). Part of my flow when a request comes in that requires auth validation is verifying the token with admin.auth().verifyIdToken, and rejecting the request if it's no longer valid.
Is it correct to:
(1) provide the client with the refresh token as well in the initial sign-in so they can handle the rejection and then request a new JWT token?
(2) perform some action on the admin SDK to refresh the token on the user's behalf
In typical oauth scenarios I've worked with before, the client has always been responsible for refreshing the token, however I can't for the life of me figure out how to retrieve a new JWT token from that refresh token using either the admin SDK or the firebase SDK
I don't know if the firebase SDK that usually resides client side is handling this token refresh behind the scenes whenever it is used with firebase.database, etc. If i'm not using that client SDK, but instead using the token as a bearer token, can I have the client pass the refresh token for exchange of a new JWT token from the backend?
It's likely staring me right in the face, I'm just not seeing it.
The Firebase Authentication SDKs keep the refresh token in the client-side code, together with the ID token, and then use the former to mint a new ID token when needed (about 5 minutes before the current one expires).
I am implementing SSO Authentication with AWS Cognito, Now I am able to successfully login a user and retrieve id_token, access_token, refresh_tokens..., and redirect the user to home page, So my happy flow is working fine,
Issue I am facing is when when ever a user is redirected to login page I check if any available session for the user with help of getCurrentUser(). Now when I login user with simple username and password I use
var cognitoUser = new AWSCognito.CognitoIdentityServiceProvider.CognitoUser(userData);
cognitoUser.authenticateUser(...)
Here I know after successful authentication token key are stored in my local-storage by aws-sdk. and these same keys are used by getCurrentUser method to fetch current user session.
Same I am not able to do in my Oauth apporach. I get the code in the query parameter and make a post call to fetch tokens. Now how to set the same token in my local storage to implement retrieveSession functionality.
The cognito sdk is specific to aws and is not a general purpose oauth sdk. Also note that this sdk (https://github.com/amazon-archives/amazon-cognito-identity-js) is now deprecated in favour of aws amplify js (https://github.com/aws-amplify/amplify-js).
If you want to use OAuth and openId connect approach, I would recommend to use oidc-client-js (https://github.com/IdentityModel/oidc-client-js).
TLDR
I am looking for somewhere to send cognito JWT's from the backend to verify the user's status.
I currently have a react app, with a serverless apollo api, and dynamodb database, all running locally.
The react client uses aws-amplify to register, sign-in etc with
aws-cognito - returning access, id and refresh tokens.
Users can also sign in with facebook and google,
amplify.Auth.federatedSignIn which returns the cognito identity
credentials.
The tokens are then passed to the backend, where they are verified.
So far I cannot find where to send the tokens from the backend, to verify that the user is signed in to cognito.
I have scoured the docs but TBH that has left me more confused.
As far as I can understand, in production API Gateway, or AppSync can intecept the tokens between the front and backend, but since I have verified tokens at the backend currently is there an endpoint or SDK method I can hit with tokens/ access keys etc to check the users status?
Feel free to tell me if I'm going about this the wrong way.
If you need to verify that a token is valid and unexpired, with the JavaScript SDK use
const cognitoServiceProvider = new AWS.CognitoIdentityServiceProvider({apiVersion: '2016-04-18'});
await cognitoServiceProvider.getUser({
AccessToken: accessToken
}).promise();
This will throw an error if the token is not valid.
If you are using a different SDK, find the equivalent call.
I have an android app that uses firebase to handle and send push notifications. When an user logs-in, it is automatically subscribed to a topic in firebase and saved the token in my database.
If after logging into the app, the users uninstall the app, their token is still in firebase, subscribed to the topic. If firebase call sendToTopic("topic"), probably will fails due this invalid token.
There is any way to get notified about those invalid tokens? I need those tokens to unsubscribe it from the topic and remove it from my database.
I have an app and I want to let people login using google sign-in. I need to check in the server what are the permissions of the current logged in user. (I have a table with email/role)
I read the documentation here:
https://developers.google.com/identity/sign-in/web/sign-in
from what I understand, when a user logs in using google, I get a callback and I can use the email and make calls to my server with it.
But what I don't understand is how can I make sure a malicious user won't see the javascript code and make a request to my server using any email he wants?
In other words, if the entire sign-in is in javascript, how can validate the identity in the server?
Assuming that you are doing the following:
Signing in from the Web
Using JavaScript for Sign-in and all data access
The following measures preventing malicious 3Ps from making API calls using your credentials / other user credentials:
API calls are domain-restricted to the authorized origins you configured in the developer console
API calls are restricted to the current credentials (e.g. only can get current user details / can only get credentials and tokens for the current user)
That said, let's move on to authN: making sure the user is who they claim to be. On the sign-in callback, you will receive a special token, the ID token, that has:
The audience for the token (your client ID)
The issuer of the token (user ID from profile)
An issued timestamp
An expiration timestamp
etc..
These values are used to prevent forgery and avoid the confused deputy problem. For example, you use these values to check claims of who the user is, that the issuer of the token was you, and that the token has not expired. You also look at the ID token signature and validate it either using JWT functionality or by passing it to the Google verify token endpoint.
After verifying the user using the ID token, you can set a cookie for establishing a session and avoid having to verify the user on every API call.
Google provides token verification samples here, for example, the Google+ Token Verification sample in Ruby. Additionally, the Google+ quickstart samples demonstrate establishing a client-server session in the "/connect" server endpoints on the server-side languages (Ruby, Python, .NET, etc).
Additional discussion on the topic is available in the Identity Cookbook.