Why are consumer key and secret needed for firebase 3rd party auth?

[Flash Bump]

Hi again.

I use twitter auth (btw, twitter4j and webview should be replaced with twitter fabric in the demo).

The app embeds the consumer key and secret declared on twitter for that app.

It's used to generate a request token, allowing the consent screen to be displayed.

Once the user as allowed the app to access his private data, an access token is given.

This last one allows the app to, say, post a tweet on behalf of the app user, and is valid as long as the user do not revoke the app.

As an optional step, user informations (such as twitter user_id, and the access token) can be saved in firebase (/users/...).

authWithOAuthToken is then called giving the access token, access secret, and user_id to firebase, so that it builds a session.

So far, so good, we are logged into our app, via firebase, via twitter.

If firebase session times out, we can query  back the access token, and do authWithOAuthToken again (bad practice?).

But why do firebase need that app consumer key and secret?

Thanks.

F.

[Rob DiMarco]

Hi -

I'm happy to answer this question for you. While Firebase supports authenticating with the Twitter OAuth token alone, we need the Twitter application key and secret in order to validate the token and retrieve the user data that becomes the contents of the Firebase authentication token and login response data. Twitter only supports OAuth 1.0a for these user-centric data requests, and each of the calls we make to retrieve that data requires signing with the app secret.

That said, we have other providers that fully support OAuth 2.0, but we've structured this workflow to be simple and consistent across each provider.

Hope that helps -

Rob DiMarco

Engineer @ Firebase

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/75a824cc-aafa-4058-a5aa-ca60c92cba19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[François Perret]

Hi Rob,

Thanks for your your answer.

When I authenticate via Twitter, and get oAuth tokens, I pass them to authWithOAuthToken firebase method, so that Firebase operates in turn as you describe. If I supply modified token or modify the consumer keys on the interface, authWithOAuthToken fails, which is great. But if I revoke the app on Twitter, the authenticate status is not propagated back via the callback to te app. Only the next call will fail: is this the attended behaviour?

So what is the best practice?

Set a small firebase session validity, and when it times out, try to call authWithOAuthToken again with the previous token (which Fabric stores locally). If that fails again, re-auth with Twitter?

Do plus and Facebook work the same way?

Thanks,

F.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAF-3uRsTwGZiaS0%3D8i5vPPL%2BHWm%2BU%3DM%3DH-dH7bcFP6G-bghrrg%40mail.gmail.com.

[Kato Richardson]

This is standard for OAuth tokens--they do not do any magical real-time checking behind the scenes. See here and here.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/ECF1104C-90CA-4960-AEC2-3665EA13EAD2%40gmail.com.