[MUSIC PLAYING]
JEN PERSON: So just between you and me,
where is that in the docs?
MALCOLM DECK: Let me just--
JEN PERSON: Because I have not been able to find it.
MALCOLM DECK: Really?
JEN PERSON: Yes.
MALCOLM DECK: No way.
JEN PERSON: Yes way.
This is quality television, folks.
SPEAKER: Scene 1, take 1.
Mark.
JEN PERSON: How's it going, Firebase developers?
Welcome back to another episode of "#AskFirebase,"
the show where we answer your burning Firebase questions.
I'm your host, Jen Person.
And today, my co-host is Malcolm Deck.
MALCOLM DECK: Hey, everybody.
I'm still working on the Firebase Authentication
team trying to provide you easy ways
to log your users into your apps.
JEN PERSON: Great, because I've gathered some new auth
questions.
Are you ready to answer them?
MALCOLM DECK: So ready.
Let's get started.
JEN PERSON: All right.
I love this question.
MALCOLM DECK: Oh, yes.
I'm pumped.
Let's do it.
JEN PERSON: Would there be any downsides to not building
a sign-out button for an app?
Just thinking along the lines of phone verifications quota,
and considering that an app is solely built on a phone auth
as primary, and assuming a single user
is going to use it always.
MALCOLM DECK: Right.
So this is actually a fairly complicated question.
There's lots of little pieces to it.
But the first thing to remember is that you actually
have 10,000 free verifications for phone authentication
every month before you start getting charged.
So until your app gets pretty big,
that should cover most use cases.
Also worth remembering is that unless your users
are choosing to sign out, the sessions that you
have remain forever.
They're persistent.
So in that respect, unless you expect users,
even if you provide a sign out button,
to be signing out a bunch, then you should be all right.
However, let's consider what the use cases are
for having a sign-out button, what needs does that address,
and that'll help you decide whether or not you want one.
So a sign-out button for phone authentication, in particular,
is useful when several people are sharing a device.
For example, a tablet that everybody uses at home.
I want to be able to play the game with my phone number,
Jen wants to be able to play the game with her phone number.
That allows us to both log in and out.
Or I want to show a friend of mine a cool app.
I need to sign out, hand them my phone
real quick for them to be able to do something.
They want to check their bank account balance or something,
and it's keyed by phone number.
Allowing people to sign out does that.
Another question worth asking yourself
is if you're already assuming that there's
only one user per device, if you don't have
a specific need for their phone number,
it might be worth just using Anonymous Authentication, where
that is a per-device session.
JEN PERSON: Yeah, that's a really good point.
So one thing I really like about this question is how much
detail they included about their use case.
That actually is really helpful for us
because you're able to really tailor
your answer to the specific needs that you're looking for.
So keep that in mind if you have questions for us.
We love to hear a little bit more about your use case
because then we can give you a more specific solution.
MALCOLM DECK: All right, Jen.
I think I've got a question for you now.
Are you ready?
JEN PERSON: All right.
Let me roll up my sleeves.
MALCOLM DECK: [LAUGHS] Umesh Kumar
asks, how can I use in-app messaging to send notifications
to single devices, rather than multiple devices,
similar to a push notification?
JEN PERSON: Thank you for your question, Umesh.
That's a great question.
And I think one thing right off the bat that strikes me
about this is that you're saying using
it to send a notification.
And that tells me that you're looking at a use case
where Firebase Cloud Messaging may be more useful.
But let's put that to the side for the moment
and talk about Firebase In-App Messaging.
Firebase In-App Messaging is messages
that appear inside your app in response
to specific events being triggered.
And rather than them being pushed all of the time,
your app periodically checks to see
if there are new messages that need to be stored locally
that are then going to appear when their analytics event is
triggered.
So it's not so much in the sense that messages are constantly
coming in.
Now you can actually send to a single device
using an instance ID, which you'll see in the console.
However, this is more for testing purposes.
So if that's what you're looking for,
you really want to test to make sure your in-app message is
showing up properly, you can use your device's instance ID.
But it's not really something that you
can do across the board, sending specific messages
to different instance IDs.
And if that's kind of the use case you're looking for,
I recommend you use Firebase Cloud Messaging.
The reason you're probably thinking in-app messaging
is because you're thinking I want to have a message appear
when I'm actually in the app.
And when we think of cloud messaging,
you'll probably think of those push notifications that show up
when you're not inside the app.
However, Firebase Cloud Messaging
also gives you access to data messages.
So what that enables you to do is send some data information--
whatever key-value pairs you want--
to your application, and then you can handle displaying them
however you choose to do so.
So in general, I'd say yes, you can
send to a single app using instance ID, similar to sending
a notification.
But that is for testing purposes.
If you need to do this on a more regular basis,
I recommend that you use Firebase Cloud Messaging,
send a data message, and configure it yourself
how you want that message to appear within the application.
So Malcolm, I'm so glad you're here
because I want to ask you about what is new in Firebase Auth.
MALCOLM DECK: So the first thing that just came out
is what we're calling generic IDP sign-in, which
is going to be in that looks very
similar to web-based sign-in in your mobile application.
So what are the benefits of generic IDP sign-in?
Well, there are several.
First of all, it allows us to support
new providers, like Yahoo and Microsoft,
which we've added to the console.
Keep sending us more requests for providers
that you want to see and we will get to adding them over time.
The other thing that this allows is
for us to allow you to continue to support Twitter sign-in.
TwitterKit is being deprecated, and you
need another way for your app to continue to interface
with your Twitter-based users.
Generic IDP allows for that.
The other benefit that this provides
is that sign-in methods for several different providers
will look more similar to you as a developer,
so that you can continue getting back
to the core functionality of your app
and let your users sign in however they want to.
JEN PERSON: Very cool.
I'm super excited about this.
I'd say Firebase Auth, comparatively speaking,
is simpler to implement than other sign-in methods.
However, this takes it yet to another level
of making things much easier on the developer.
MALCOLM DECK: Right.
We've put a lot of work in to make sure
that you don't have to deal with the complications
of mobile operating systems for a lot of the tricky parts
of this.
So hopefully, implementation on your end will be really easy,
and we'll worry about all the difficult parts.
JEN PERSON: You'll worry about it.
[LAUGHS]
MALCOLM DECK: We actually have one other exciting thing
in Firebase to announce right now,
which is that we have integration with risk.
So what that means is for your Google-based users,
when a malicious sign-in happens on their Google account,
it will automatically sign them out
of their Google-based Firebase account.
So your users will be protected across all applications
for Google accounts.
We're really excited about that.
We want to help keep everybody safe.
That's the whole reason you have a login system
in the first place, right?
JEN PERSON: Yeah, definitely.
That's a really cool feature.
Wow.
So this is really exciting.
I can't wait to see what new providers are
added in the future and what features you have.
I'll definitely have to have you back on the show
to tell me what else is new in the future.
MALCOLM DECK: We have a lot of exciting stuff coming.
Keep an eye out both at Google I/O and at Cloud Next
to hear what else is coming for Firebase Authentication.
JEN PERSON: Cool.
Malcolm, thanks so much for coming on the show.
It's always a pleasure to have you here.
And thank all of you that provided us with questions.
We really can't make this show without you,
so remember, if you have a query about Firebase,
be sure to tag it on social media
with the hashtag #AskFirebase.
That makes it more visible to us and I can get it
to the people that an answer.
And who knows, you might even see it on a feature episode.
And if you like the content you see
here, be sure to subscribe to the Firebase YouTube channel
for all sorts of other great videos.
Thanks so much for watching, and we'll
see you on a future episode.
Bye-bye.
OK.
MALCOLM DECK: It's great.
JEN PERSON: Thank you.
MALCOLM DECK: I learned so much.
JEN PERSON: Thank you for doing that so now we don't have to.
It was like, that was easy.