Firebase Demo:
Anonymous SignIn
with Web Component
INTRO
Why would you want new users to sign in anonymously, without providing any personal or contact information? From Firebase's point of view, this is all about building trust with your users, it lets them test out your app, with access to as little or as much of your data as you allow (using secure rules). You can then later, after your desired time or usage period, ask these anonymous users to properly register, or just delete their anonymous account after 30 days, or perhaps you just do not need to know anything about your users, so they could just carry on being anonymous.
Your app will need to capture and store, as a minimum, the REFRESHTOKEN, which is requirement for returning a working IDTOKEN, so that the anonymous user can read/write data
As a developer, you are going to need the API key and the Firebase URL. These can all be found in the project settings for the database. You should also set up a tag/ProjectBucket for the database. I will use demoANON for this. For the purposes of the demo I will refer throughout as follows:
API Key === AIzaShC3m_gRuFjgH61xBV2S4ZKJL0m1pTpWRM2
FirebaseURL === https://myProject.firebasio.com/
Project Bucket / Folder === demoANON
You will need to enable Anonymous signin in the Authentication/SignIn methods section of your Firebase project
If I show any user tokens, they will probably be as they are, or shortened for viewing purposes, they will have expired by time of going to print!
For the realtime database, I will use the rules that only allow an authenticated user who is anonymous to write to and read data from their own area, and set just for demoANON:
{
"rules": {
"demoANON": {
"$uid": {
".read": "$uid === auth.uid && auth.token.firebase.sign_in_provider === 'anonymous'",
".write": "$uid === auth.uid && auth.token.firebase.sign_in_provider === 'anonymous'"
}
}
}
}
This example shows a simple app where the user can save their favourite number in Firebase, and this is returned to their app. The user can change their favourtie number when ever they like.
Firebase Realtime Database with Anonymous SignIn
SIGN IN an Anonymous User
Url:
https://identitytoolkit.googleapis.com/v1/accounts:signUp?key=APIKey
PostText:
returnSecureToken=true
Example:
https://identitytoolkit.googleapis.com/v1/accounts:signUp?key=AIzaShC3m_gRuFjgH61xBV2S4ZKJL0m1pTpWRM2
returnSecureToken=true
Returns: (note "idToken" and "refreshToken" have been shortened)
{
"kind": "identitytoolkit#VerifyPasswordResponse",
"localId": "uBzLUCxxP9VOuahNseg878JdB6E3",
"idToken": "eyJhbGciOiJSUzI1NiIsImtpZCI6ImQxMGM4Zjhi...IhawGQXLn-gOlVJQ4KxenovzOSUV_wmA",
"refreshToken": "AG8BCndcseQhtIH2mOXQ-55vqu0wJl6y1...P4D6o515CMNt8pRE",
"expiresIn": "3600"
}
REFRESH idToken for user
The idToken for a user, once signed in, will last for an hour, then it will need refreshing. You use the refreshToken shown in the signin return above to do this.
Url:
https://securetoken.googleapis.com/v1/token?key=APIKey
PostText:
grant_type=refresh_token&refresh_token=theRefreshToken
Example:
https://securetoken.googleapis.com/v1/token?key=AIzaShC3m_gRuFjgH61xBV2S4ZKJL0m1pTpWRM2
grant_type=refresh_token&refresh_token=AG8BCndcseQhtIH2mOXQ-55vqu0wJl6y1...P4D6o515CMNt8pRE
Returns: (Note "access_token","id_token" and "refresh_token" have been shortened. Note also that the access_token == the id_token)
{
"access_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6Ijc...tRDUzId0_Wgjm3MW6-AkZ1j38a1zXg",
"expires_in": "3600",
"token_type": "Bearer",
"refresh_token": "AMf-vBwPNHd1ZK324sqh7zO59hJlK...GiYBVUYi0TPqgjzT4LAb74QnvYTgYO7NsmR44",
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6Ijc...tRDUzId0_Wgjm3MW6-AkZ1j38a1zXg",
"user_id": "2HQIFCAifCVDAy5Ogu8VeNhwUPk1",
"project_id": "679881131398"
}
Use the new idToken for access to the firebase data
BLOCKS
You will see in the blocks that I have only used one web component for three different actions. These are set when the action is run, and then used as a test when data is returned from Firebase. In essence the workflow runs like this:
On first use, the user presses SignIn, and the action "signin" is activated.
This returns signin data, and the idtoken,refreshtoken and uid are stored to a tinydb
The user can now store their favourite number, and this will be returned from Firebase and displayed in the app
You can see that the user's data is stored in the Project Bucket demoANON and under their uid, only the user with that uid and idtoken can access that data.
The use will remain signed in for an hour, after which they will not be able to change their favourite number.
Therefore they must use the refresh token to fetch a new idtoken.
Pressing on Signin again, this time the app finds a refresh token in the tinydb
The refresh action is initiated, and the new idtoken is returned, along with the refresh token and user id, all of which are updated to the tinydb
The user can once again update their favourite number as before
You should see from this the importance of storing the refreshToken. Without this, the anonymous user would not be able to signin or access their data
DATA ON FIREBASE
SCREEN
(the demo display all responseContents as text in a label, to help you see what is happening)
In Summary:
Anonymous signin appears to have its uses, and greatly simplifies initial access for new users to your app.