I have a scenario where I need to do a secure request a Firebase Cloud Function from an external server using a HTTP request. In order to request it I need to send a bearer JWT token on the authorization header. After sometime looking at the Google documents to Firebase/GCP I've found many different ways to authenticate using google different APIs, but I'm kinda lost on it.
I know that I need to use a service account in order to identify the machine that is calling instead a common human-user credentials. I also know that the service account provides a JSON file that contains secure information to identify that service account, like the private key. By looking different docs I found this one that explains how to generate and request a token. After following those steps, I'm facing a 403 status when I try to call the cloud function using the resulting token.
I doubled checked the roles my service account has and I do have the ones the docs have pointed me.
Does anyone knows or have any suggestions how to proceed to have cloud function authorized calls by a machine (not human) interaction.
Edit 1:
As requested here I'm posting my JWT generator code:
const {
private_key_id,
private_key,
client_email,
} = require('./serviceAccount.json');
const jwt = require('jsonwebtoken');
const payload = {
"kid": private_key_id,
"iss": client_email,
"sub": client_email,
"iat": 1611257400,
"exp": 1611260940,
"aud": "https://oauth2.googleapis.com/token",
"target_audience": "https://<project- region>.cloudfunctions.net/helloWorld"
};
const token = jwt.sign(payload, private_key, { algorithm: 'RS256', header: {"alg":"RS256","typ":"JWT"} });
console.log(token);
With the result token from above I'm sending a POST request to https://oauth2.googleapis.com/token where the token is sent as the assertion field on a form data.
After suggestions here I did some research and found this blog with instructions to generate a Identity token using my service account. So I ran:
# Load the service account identity
gcloud auth activate-service-account --key-file=key.json
# Generate an id token
gcloud auth print-identity-token
The resulting token gave me the same result a 403 - Forbidden error. The interesting part is that using my user credentials and using gcloud to generate an identity token I was able to request the Cloud function with a 200 result.
I'm thinking that I'm missing some sort of role/privilege/scope on my service account configuration.
Make sure that the service account has assigned the cloudfunctions.functions.invoke in order to guarantee that the Cloud Function can be triggered from an external server using an HTTP request.
Related
I'm pretty new to FastAPI and OAuth2 in general. I just worked through the tutorial "Simple OAuth2 with Password and Bearer" and it mostly made sense, but there was one step that felt like magic to me..
How does the access token get stored onto the client and subsequently get passed into the client's requests?
My understanding of the flow is that it's basically
User authenticates with their username and password (these get POST'ed to the /token endpoint).
User's credentials are validated, and the /token endpoint returns the access token (johndoe) inside some JSON. (This is how the user receives his access token)
???
User make a subsequent request to a private endpoint, like GET /users/me. The user's request includes the header Authorization: Bearer johndoe. (I don't think the docs mention this, but it's what I've gathered from inspecting the request in Chrome Developer Tools)
The authorization token is then used to lookup the user who made the request in (4)
Step (3) is the part that I don't understand. How does the access token seemingly get stored on the client, and then passed as a header into the next request?
Demo
When you run the code in the tutorial, you get the following swagger docs. (Note the Authorize button.)
I click Authorize and enter my credentials. (username: johndoe, password: secret)
And now I can access the /users/me endpoint.
Notice how the header Authorization: Bearer johndoe was automagically included in my request.
Last notes:
I've checked my cookies, session storage, and local storage and all are empty
The authorization header disappears if I refresh the page or open a new tab
I suspect Swagger is doing something under the hood here, but I can't put my finger on it.
If you need persistence for the token you'd usually use localStorage or similar, but in SwaggerUIs specific case, the authentication information is kept internally in the library.
If you have enabled persistence SwaggerUI will persistent the access token to localStorage:
export const persistAuthorizationIfNeeded = () => ( { authSelectors, getConfigs } ) => {
const configs = getConfigs()
if (configs.persistAuthorization)
{
const authorized = authSelectors.authorized()
localStorage.setItem("authorized", JSON.stringify(authorized.toJS()))
}
}
I have a web application where users can sign in with Google.
To the sign-in process, I add a scope to be able to access Google Calendar.
Now that the user is signed in, I would like to - in server-side - get their current Google access token in order to make a request and get a list of their events.
Is there a way to get the current OAuth token (no need for refresh token) in order for me to make this completely on the server-side?
I'd say that you can check this article and put special attention to the recommendation for websites.
I understand you have configured already the consent screen, which is the first step of the basic steps on using OAuth 2.0. So I understand that you only have to perform the following steps:
Obtain an access token from the Google Authorization Server
Examine scopes of access granted by the user.
Send the access token to an API
I think you can also give a look to this other doc for more GCP insights over your goal to authorize the request using user tokens
Edited:
Regarding the Firebase Authentication, I understand this happens at the user's device, and you could use some code to retrieve the token and then send it to your back end servers as mentioned in here.
As a sample here there's the sample code for retrieving the token in Android:
FirebaseUser mUser = FirebaseAuth.getInstance().getCurrentUser();
mUser.getIdToken(true)
.addOnCompleteListener(new OnCompleteListener<GetTokenResult>() {
public void onComplete(#NonNull Task<GetTokenResult> task) {
if (task.isSuccessful()) {
String idToken = task.getResult().getToken();
// Send token to your backend via HTTPS
// ...
} else {
// Handle error -> task.getException();
}
}
});
A little about OAuth 2.0
Whenever a user signs up to your app/website via Google or 3rd Party, an Authorization Code, this Authorization Code is exchanged for an AccessToken & RefreshToken.
The AccessToken sent via Google are valid generally for 60 minutes.
Offline Access (Server Side)
Let's break it down to two parts:
If your need to update within 60 minutes of user's last activity
You can use firebase along with gapi to achieve that. You'll be provided with the AccessToken that can be sent back to server to add to calendar.
More info on implementation
If you need to update after 60 minutes of user's last activity
Firebase & gapi's most method handle the AuthorizationCode flow internally. They even further refresh the AccessToken after 60 minutes. This is beneficial for most developers as they won't have a headache of managing all the tokens.
This method but, hides RefreshToken & AuthorizationCode from the developer. That is even if your server has the access token, it won't be able to refresh it and it would be deemed useless.
To achieve complete offline access, in the initial request to get AuthorizationCode you will need to send a HTTP GET parameter access_type to offline
GAPI provides you with grantOfflineAccess() method which returns the AuthorizationCode that can be later used on your server to fetch access token & refresh token.
Note: If you are storing AuthorizationCode in your database, make sure it is secure. The limitation in Firebase are set due to security reason. It is more secure to not talk with AuthorizationCode generally.
More links
https://developers.google.com/identity/protocols/oauth2/web-server
https://developers.google.com/identity/sign-in/web/reference
https://developers.google.com/identity/sign-in/web/server-side-flow
https://developers.google.com/identity/sign-in/web/backend-auth
Retrieve Google Access Token after authenticated using Firebase Authentication
Due to some constraints of my project I need to manage my api server and database separately from firebase, however there is nothing stoping me from using their other tools like analytics and in this particular case authentication.
I wanted to ask if following scenario is possible:
I authenticate user on my client app using their SDK's
I send relevant jwt data in headers of my API
Can I then somehow validate this on my server, so in essence avoid complex auth service and use firebase for this instead? Are there any examples, preferably for NodeJS server.
Yes you can, it's very common use case and firebase auth has been made with such usage in mind. As you said, send jwt data on headers, then on the server, you verify the token with firebase service:
var admin = require('firebase-admin');
admin.initializeApp(); //may require other steps, see last link
// idToken comes from the client app
admin.auth().verifyIdToken(idToken, true)//second argument is optional, checks whether the ID token was revoked
.then(function(decodedToken) {
let uid = decodedToken.uid;
// ...
}).catch(function(error) {
// Handle error
});
https://firebase.google.com/docs/auth/admin/verify-id-tokens
https://firebase.google.com/docs/reference/admin/node/admin.auth.Auth#verifyidtoken
https://firebase.google.com/docs/admin/setup
I'm trying to test my application that uses Firebase for push notifications using postman.
I'm specifically testing the Http v1 Api, and looking how to authorize the request.
What I need to get right is getting the OAuth2 token to use in Postman, which I should be able to do on the OAuth 2.0 playground although I'm not sure how.
I have my privatkey.json file that I've downloaded from the firebase console, I just need to know how to use it to get the token that I would add as a bearer authorization header for my POST requests
I was able to send a message through the FCM v1 HTTP API by requesting the following scopes in the OAuth2 playground:
email, https://www.googleapis.com/auth/firebase.messaging
After authorizing this, I exchanged the authorization code for refresh and access tokens.
I then passed the resulting access token into the call with FCM:
curl -X POST -H "Authorization: Bearer MY_ACCESS_TOKEN" -H "Content-Type: application/json" -d '{"message":{
"notification": {
"title": "FCM Message",
"body": "This is an FCM Message",
},
"token": "MY_DEVICE_TOKEN"
}
}' https://fcm.googleapis.com/v1/projects/MY_PROJECT_ID/messages:send
In the above CURL request replace the following placeholders with the relevant values for you:
MY_PROJECT_ID is the Firebase project ID, which you can get from the project settings page in the Firebase console
MY_DEVICE_TOKEN is the registration token of the device that you want to send the message to. For a web client, see how to get the current registration token.
MY_ACCESS_TOKEN is the OAuth2 access token that you got from the OAuth2 playground using the steps outlined above.
The FCM documentation on authenticating FCM v1 requests may be confusing since it only calls out the OAuth2 token. It actually first generates a self-signed JWT (JSON Web Token) by calling new google.auth.JWT(...). This involves downloading a private key, and generating the JWT locally through a JWT library.
The self-signed JWT is then passed to jwtClient.authorize(...), which gives back tokens including an access_token. The latter is an OAuth2 access token, similar to the one we got above.
I created a small project on hithub that includes both a postman collection and environment and nodejs project that uses the downloaded service-key.json to generate an access token which solves my problem above. It's not as elagent as using only postman (which to me seems impossible), but it works well enough since the access tokens live for about an hour.
I've spend the last few days reading through all the specs with regards to OAuth2 and OpenIDConnect and implementing a test client using Thinktecture Identity Server. I've also followed several pluralsight courses and I think understand the main gist of it. However i'm still extremely confused about the Response Types.
OpenIDConnect spec specifies that the Hybrid flow response types are a combination of "code", "id_token" and "token". I understand the "id_token" allows us to get access to basic id information initially.
I also understand code" refers to the authorization code and "token" refers to an access token and combining "code" with one or both of the other two triggers the flow but my understanding was that you swap an authorization code for an access token in the Authorization flow, while the Implicit flow supplies the Access Code implicitly?
Could someone clear up my confusion?
The following statements that you made are correct:
code refers to the Authorization Code
token refers to an Access Token or (access_token)
in the Authorization Code flow one switches the code for an access_token
But part of your confusion may originate from terminology mixup:
the term Authorization flow is not entirely correct; its official name is Authorization Code flow
the term Access Code does not exist
the Implicit flow does not have an Authorization Code (nor Access code) in fact there's no credential (or grant) involved at all that allows the Client to get tokens from the Token endpoint, hence it's name
As #juanifioren pointed out, Hybrid flows combine things:
the code id_token flow would get a code and id_token in the Authentication Response directly but you'd use the code to get an access_token from the Token endpoint
the code token flow would get a code and access_token in the Authentication Response directly but you'd use the code to get an id_token and possibly another access_token in the backend from the Token endpoint
the code id_token token flow would get a code, access_token and an id_token in the Authentication Response directly and you could use the code in the backend to get another access_token from the Token endpoint
Getting an access_token from the Token endpoint differs from getting it from the Authorization endpoint because the confidential clients authenticate themselves to the Token endpoint (and not to the Authorization endpoint). Hence the access_token for the confidential part of the client might have more permissions and or a longer life.
See also a short thread on the spec mailing list on this topic: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20150209/005229.html
To understand the possible relationships between Response Types and Grant Types see IdentityServer4\Constants.cs
public static readonly Dictionary<string, string> ResponseTypeToGrantTypeMapping = new Dictionary<string, string>
{
{ OidcConstants.ResponseTypes.Code, GrantType.AuthorizationCode },
{ OidcConstants.ResponseTypes.Token, GrantType.Implicit },
{ OidcConstants.ResponseTypes.IdToken, GrantType.Implicit },
{ OidcConstants.ResponseTypes.IdTokenToken, GrantType.Implicit },
{ OidcConstants.ResponseTypes.CodeIdToken, GrantType.Hybrid },
{ OidcConstants.ResponseTypes.CodeToken, GrantType.Hybrid },
{ OidcConstants.ResponseTypes.CodeIdTokenToken, GrantType.Hybrid }
};
Your thoughts about Authorization Code Flow and Implicit Flow are right.
But I think you are over-complicating the hybrid flow. When using hybrid you just simply can get both code and id_token.
After that, either you can grab code and exchange it for access token or just use the id_token (or access token) directly. Both approaches have their own flaws, especially in terms of security.
https://medium.com/#darutk/diagrams-of-all-the-openid-connect-flows-6968e3990660#9401
6. response_type=code token
When the value of response_type is code token, an authorization code
and an access token are issued from the authorization endpoint, and an
access token is issued from the token endpoint. In addition, if openid
is included in the scope request parameter, an ID token is issued from
the token endpoint, too.
Both the authorization endpoint and the token endpoint issue an access
token, but the contents of the access tokens are not always the same.
Regarding this, “3.3.3.8. Access Token” in OpenID Connect Core 1.0
says as follows:
If an Access Token is returned from both the Authorization Endpoint
and from the Token Endpoint, which is the case for the response_type
values code token and code id_token token, their values MAY be the
same or they MAY be different. Note that different Access Tokens might
be returned be due to the different security characteristics of the
two endpoints and the lifetimes and the access to resources granted by
them might also be different.