("Superpoints" and "Megashop" used below are fake business names)
I am using Firebase Auth to authenticate users in my (Android) app ("Superpoints"). My users can earn points for using my app, they can later spend when paying for something.
I want to integrate with a partner ("Megashop") in the following way:
Alice opens the Superpoints app on her Android phone.
In the app she clicks on "Megashop campaigns".
A web browser or a web view (whichever is fine for me) for superpoints.megashop.com opens. The opened page has a button like "Login with Superpoints account".
Alice clicks on "Login with Superpoints account" and provides her credentials (this can be email+password, log in with phone number, log in with Google Account).
The system checks if Alice's accounts exists in my user database and sends back the response to Megashop with Alice's Superpoints membership ID and her balance (for example: "{ memberId: 100500, points: 42 }").
After Alice purchases something in Megashop, their checkout hook sends a request to HTTPS endpoint for a cloud function that adds an amount of points (for example, 250 points) to Alice's balance (something like https://app.superpoints.com/accrual?partner=megashop&memberId=100500&points=250).
On my app's website, I do the authentication using FirebaseUI Auth, in the app I'm also using FirebaseUI (library for Android).
Now finally the questions: How to authenticate my users on a third party's site? What are the best practices? Should I build some kind of a gateway for the third party, or is there an easier way for doing that?
This is a classic case of OAuth.
Firebase Auth, as far as I know, does not support acting as a OAuth provider.
Related
Background
Google is kicking people out of Google Sign-in JavaScript library (platform.js) and pushing people to migration Sign In With Google by Google Identity Services library (gsi/client). (Migration Guide)
Anyone must go through this migration by March 2023. The new flows are cool (e.g. One-tap) and should make life easier.
Problem
In the new flow, Authentication and Authorization are separated! If you just need basic scopes (e.g. email, basic profile), then Authentication should be enough.
With that, you get an ID Token (a JWT) that you can verify on server-side.
The problem is, revoking this token (as listed in Revocation Methods) can only be done either manually by the user in their own Google Account, or it should be done on client-side. No server-side option is present.
The Case
Our platform supports sign in with Google, Apple, and email/password.
The same user uses Google Sign In on Web and Apple Sign In on their iPhone. (same email address.)
Per the forces of Apple, since June 30, 2022, we should provide a delete account option.
User signs in with Apple Sign In to our platform and requests deleting their account.
We can (and must, again per Apple) revoke Sign In with Apple by calling Apple's Server-to-Server Revoke Tokens endpoint. But Google doesn't provide such an option for ID-Token. :(
Any idea how to solve this?
Current alternatives
1) Use Authorization and store access_token and refresh_token
(Per Google Identity > OAuth 2.0 > Server-side Web Apps > Revoking a token) OAuth revoke takes an access token or refresh token.
The old gapi library of Google Sign In for Web, was granting access token on sign in. The new one doesn't. So we have to explicitly ask for an access token via Authorization flows, and store it/refresh-token in the DB and maintain it. That's overkill, but works.
2) Do it in client-side and cover the most, not all
It can be done on the client-side when the request for delete-account is sent to the server. However, it only covers signed-in-with-Google users. This means that the mentioned use case (signed in with Apple) wouldn't be covered. But, hey, it's a cheap and fast solution!
We are using Azure B2C for login/authentication of our users. This works fine on our website (social and email login etc).
Our mobile app is built in Xamarin forms and we are trying to build a native login experience (using native app controls vs. a web view within the app that B2C presents) that integrates natively with the device biometrics for login (FaceId, TouchId, fingerprint login).
As you can imagine, doing this in the webview that Azure B2C requires doesn't allow a native login experience.
The overall goal here is 2 fold:
Build a native login experience
Integrate with biometrics.
Question:
Does Azure B2C have an API that enables this, especially so we can use authorization code flow without a UI. ROPC exists but does it integrate with social accounts too?
If not, is there a way to integrate biometric login with Azure B2C on mobile when the login screen is presented in a webview? So that when the B2C login page in the webview is presented, a user can login with touch/faceId and save that information to they keychain (on iOS and the equivalent on Android)
You need to use Webviews, and you can enable Biometric integration with webview type experience.
You cannot integrate any service with Social Accounts and ROPC. Any integration with Social IdPs will need a webview.
Yes, enable Keep Me Signed In for long lived sessions. Wrap the biometric code around the acquireTokenSilent() methods.
Then you have two options:
You can hide the KMSI button, and use JavaScript to force select the KMSI checkbox in the login page using page customisation.
You can rename the KMSI label on the login page to ask the user if they want to enrol in to biometric. Then after the login, your app will receive a claim in the token whether the user opted in, use claim resolver to achieve that.
Now you have a user logged into the App, with:
1 hour access token
Potentially up to infinity long refresh token
Multi day/year Azure AD B2C session cookie
Then, when the user re-attempts to open the app, or perform some action in the app, you will need to call acquireTokenSilent(). This MSAL method obtains a fresh access token for the required API resource/scope.
If the token is expired, or requires a different scope, the a new token is fetched.
You can wrap any action in your application with the biometric SDK.
if (performingSomeAction && requiresBiometric)
if (challengeBiometric succeeds)
acquireTokenSilent()
//do someAction
Now if the refresh token has expired, then the web view will pop up, the long lived session cookie will be used to get new tokens. The acquireTokenSilent() method handles all of that already.
In Firebase, it is possible to log in a user as anonymous with a token, and when the user decides to register, just update the credentials. I have a hard time understanding whether the same is possible with Auth0.
We are now using Auth0 as identity provider, the flow is the following:
The user is using the app anonymously with limited access.
User registers in the app with Auth0.
Auth0 issues a token
Firebase receives the token and lets the user use the restricted parts. All the data generated by the anonymous user is lost
What I want to achieve:
When the user starts using the app, Auth0 immediately creates a user token
The token is valid to access certain parts of Firebase database
If/when the user decides to register, their token remains valid but receives additional credentials
Firebase lets the user use the restricted parts
It's Konrad from Auth0 Community Team. Yep as Baskaro said unfortunately it's not supported from our side of stack. It will be great if you can submit it as a feature request to our product team using our feedback form (you will be contacted by one of our product managers within 10 business days):
https://auth0.com/feedback
I wonder if anyone can help. I'm trying to plan the AWS services that I'll need, and how they hang together, for a web application I'm planning.
Specifically I'm thinking about the user registration and login process using Cognito and DynamoDB.
Users will need to be registered and logged in in order to perform some actions. I'm thinking serverless, so these actions will be Lambda functions fronted by API Gateway. As with many websites, I'd like to use Facebook as the user authentication model. I'm thinking I need:
To create a Facebook application
To configure Cognito Federated Identities with the Facebook app id
To have a DynamoDB table to contain user information
To provide a facility to allow a user to register using their Facebook identity
On registration, create a record in the DynamoDB user info table with user's name, email etc as taken from their Facebook profile
To provide a facility for registered users to login with their Facebook identity
To somehow pass the user token (JWT token ?) on subsequent client requests to API Gateway endpoints
So far I've created the Facebook app and have an application ID. I've created the Cognito Federated Identity for the app and configured it with my Facebook app id. And I have set the Authorisation field for the Method Request for the API Gateway to "AWS_IAM"
Using the Facebook javascript SDK and the AWS javascript SDK, I've put together a very basic page that allows login via Facebook, then creates a new AWS.CognitoIdentityCredentials object with the facebook authResponse accessToken. Lastly it calls AWS.config.credentials.get to get the Cognito credentials. But this isn't really the steps above - it just proves that a user can login with their Facebook id and I can pass it to Cognito.
My specific questions therefore are:
What I'm trying to work out is how to do registration. Once the user has logged in via Facebook, how can I create a user record in DynamoDB?
And likewise, when a user goes to login (rather than register), once the user has logged in via Facebook, how can I ensure they have a user record in DynamoDB? (because if they dont have a record, then presumably they've not registered)
Lastly, how can I pass the user id / token from the client to an API Gateway endpoint?
I'm not looking for code samples etc - just pointers as to whether I'm thinking along the right lines or barking up the wrong tree. A high level of how the various components need to hang together would be great, as would any links or references to similar ideas of concepts.
Thanks
I am working on Firebase application ( Firebase version 4.1.3 )
My health care related application is made for dependent group of people such as children and seniors. However, most of my users are independent group of people age around 18-55. Most of my users use my application for their seniors/children. They need to create account for each of their family seniors/children member. Therefore, my users have to log in and out many times and they have to keep track of their family members' account. My first thought was I should make an account switching feature so that my user can switch their account back and forth between their family members to update information on my application.
After searches on Google, I found way to force switching account on Firebase authentication with Google provider, but those are not what I'm looking for.
My questions are:
Is it possible to store the multiple firebase auth objects (logged in object) in client side?
If it is possible, for how long will the token inside the firebase auth object last for?
If it doesn't last forever, is it possible to refresh update the token so that it can be use without authenticating with the social/phone login again?
The functionality you are asking for is not available out of the box. You have to build it on your own. I do think Firebase provides the pieces to allow you to build it (via Auth and Database).
Is it possible to store the multiple firebase auth objects (logged in object) in client side: You can have multiple Firebase app instances and each one have an auth instance with a current user. You would need to ask each user to authenticate though (you can't authenticate once and sign-in into all of the account). However, you can build your own user group login mechanism, where logging in with one "master" account can allow you to login with multiple accounts using custom Auth.
If it is possible, for how long will the token inside the firebase auth object last for. Firebase sessions are supposed to be indefinite. If a token expires (typically after one hour), it can be refreshed automatically if you are using real time database.
I do not think Firebase has that token capability. But what you could do is simply put the email address of the people in the device by Shared Preferences( for Android). When the user wants to log in with that user bring the email address just ask him to enter the password and then go through the log in process. If you do not want to use SharedPreferences you could simply store the users(also as you said family members) in Firebase Database and link them with the controller user so to speak. Whenever user wants the switch, go and bring the email addres of other family members from Firebase Database and ask in the client for the password and do the login by Firebase Authentication.Hope that helps!