Tried following the instructions here:https://firebase.google.com/docs/auth/server/create-custom-tokens
to create a firebase custom token and on the server and then trying to sign in to firebase through the iOS SDK but getting this message with the custom token "The custom token corresponds to a different audience."
I am trying this use the node sdk, also tried the php route creating the token with third party jwt library. Is this broken in firebase 3.0?
It's likely that the service account you are using to mint the custom token corresponds to a different project than the one you are using in your iOS client. The backend node server minting the token and the client calling signInWithCustomToken should belong to the same project.
Related
Is there a way to add firebase auth as provider to my custom backend? For my custom backend I am using directus. Directus offers to add auth providers that supports oAuth 2.0 and openID Connect (docs). But I do not know if firebase auth can be used as an oAuth provider, I did not find about it in the firebase docs.
I am using flutter for the frontend part
Firebase does not expose OAuth tokens for its user, so you won't be able to use that integration directly. If you're allowing your users to sign in to Firebase with a social provider (Google, Facebook, etc), you can also pass that token to directus, instead of (or in addition to) signing in to Firebase with it.
Otherwise you can take the ID token that Firebase creates for the user, and verify that in your backend code. You won't be using directus' sign-in functionality in that case though.
I also recommend reading: Demystifying Firebase Auth Tokens for an explanation of Firebase's token types.
I'm integrating Okta into an iOS app and I need to create a custom new user registration UI. I can't seem to find anything on this in the documentation but this must be a common use case.
Is there an SDK available to help with this (similar to login) or will I have to hit the APIs manually?
You will need a backend application to make a call to Okta to create user if you need a custom registration UI as it requires an API token or access token with high privilege.
You can use one of the management SDK's based on your backend application language.
You can find some links below:
.Net SDK: https://github.com/okta/okta-sdk-dotnet
Java SDK: https://github.com/okta/okta-sdk-java
Hitting this endpoint manually is the solution. Just make sure you're providing an API token, not a user token.
I'm trying to setup account linking in dialogflow agent using this documentation, I've created my credentials from the Google cloud platform. when I'm trying to put that credentials data to Actions on Google console, it gives an error as shown in below picture.
I've put these Authorization URL and token URL from my credential JSON.
The error says: Google accounts cannot be used as Auth endpoint urls per our Account Linking policyLearn more
I want to know about the following:
What this error means.
how to solve this issue.
The error is exactly what it says - if you are setting up Account Linking using the Auth Code Flow, you're not allowed to use Google's servers as your authentication endpoints. You're expected to have your own OAuth server (or use one such as Auth0) to do this.
How to resolve this depends on your exact needs and exactly what you have available to work with:
Setting up your own OAuth server
If you have an existing service that has accounts already, you would likely want to link the user's account in your service to their Assistant account.
To do this, you would need to setup an OAuth server. If you are already using one as part of your existing service, you can configure it for the Assistant. If not, Google provides information about the minimal implementation requirements or you can use existing libraries.
Using OAuth as a Service
You can also use a service such as Auth0 to provide authentication. Depending on your needs, this is a good service that allows people to log in using a range of providers and gives you an API to access their accounts maintained on Auth0.
Using Google Sign-In for Assistant
Finally, if you are either using their Google Account in your own service, or you just want a way for them to log in using their Google Account, you can use the (still in preview) Google Sign-In for Assistant. This will give you an ID token as part of your fulfullment which contains the Google ID
Not sure if that is possible: I would like to switch from server flow to native client flow in order to provide a better authentication experience for my users.
The problem is that Azure AppService requires a "web application" OAUTH setup (contains client ID and a secret), while the native login works with just a client ID and not secret. This means that after the login on the phone, I do have a Google token, but AppService wouldn't know what to do with it and returns me an HTTP Unauthorized.
The mobile client SDK gives me an API, but that doesn't work with such a token.
var jObject = new JObject(
new JProperty("access_token", auth.AccessToken),
new JProperty("id_token", auth.IdToken));
await ServiceClient.LoginAsync(MobileServiceAuthenticationProvider.Google, jObject);
Any idea on the proper way to integrate this without having to write my own server-side token validation?
You would still need to configure the web application in Google since you are attempting to access a non-Google API. The native login on its own is not enough.
That means you will still need to provide the backend with an ID and secret. The client is responsible for obtaining an id token and authorization code which get sent to the server, and the server does the actual retrieval of the access token, per the Google documentation.
So that means your call will actually look something like the following:
var jObject = new JObject(
new JProperty("authorization_code", auth.ServerAuthCode), // not sure what property your auth binding exposes this as
new JProperty("id_token", auth.IdToken));
await ServiceClient.LoginAsync(MobileServiceAuthenticationProvider.Google, jObject);
There isn't documentation for the end-to-end using Xamarin.Android, but you might find it useful to glance over the App Service iOS documentation for this scenario just to see the moving parts. The general pattern you will follow is:
Configure everything for the server flow (as you've done before)
Set up the Google Sign-in SDK (seems like you've done that already, too).
Make the call as described above
The main issue you might run into is making sure that you have the API console registration correct. You'll want to make sure you have an Android client there connected to the web application client ID you are using. I'd recommend giving the Google Sign-in for Android setup instructions a quick look. Also note that authorization codes are one-time use, and there are some throttles that Google puts in place for a user requesting too many of them within some span of time. You might run into that during dev.
AS far as I know, the native client flow also use the google code flow to get access token.
According to this article, the Android, iOS, or Chrome applications doesn't need the secret to get the access token.
The client secret obtained from the API Console. This value is not needed for clients registered as Android, iOS, or Chrome applications.
But the web app backend will not authorized this access token if you don't set in your backend to enable Azure App Service authentication/authorization. Because the backend will have its own logic(the mobile server library write the logic according to the access token) to return the auth token according to the access token.
Now, the most easily way to enable the client flow in your mobile app is set in your backend to enable Azure App Service google authentication/authorization with the same clientid and secret(based on my test: if you don't set the right secret, the backend will still return the auth token).
Here is the test image:
If you still don't want to enable the app google easy auth, I suggest you could create custom authentication which contains your own logic to check the accesstoekn and get the user information from the google.
If the checked result is success and get the enough value, you could generate the auth token and return to the client side.
More details about how to create custom authentication in the mobile app backend , you could refer to this article.
We have an existing application on SoundCloud that was created some time ago and set up to use OAuth1. Recently we needed to expand SoundCloud-related functionality and, because of some problems with the old library, had to upgrade to new cocoa-api-wrapper library that uses OAuth2 client.
The problem now is that we cannot access our application with its key/secret because of the different version of OAuth. While it is possible to set up new application and get new key/secret pair, we wouldn't want to lose all the data associated with the current application.
Is there a way to have the same SoundCloud application accessible with both versions of OAuth (OAuth1 is still being used)? If not, what's the best way to handle this situation?
Yes. You can migrate an OAuth1 token to an OAuth2 token by sending a POST request to the following endpoint:
https://api.soundcloud.com/oauth2/token
with the following parameters:
client_id='YOUR_CLIENT_ID'
client_secret='YOUR_CLIENT_SECRET'
grant_type='oauth1_token'
refresh_token='OAUTH1_TOKEN'
The response will contain an OAuth2 token (as well as expires_in, scope, refresh_token).