I am trying to send a Firebase notification using the HTTP v1 api.
The process described in google's guide states, that I create a service-account-file.json and later use that with the Google Auth Library, which does work.
However, I was wondering if there is a way to do this without using the library, via a POST/GET request, the issue is, I can't find a way to avoid having to go through the google's oAuth-2.0 consent page (to get the authorization code to later exchange for an access and refresh token), mentioned here.
Is there another way just by using the content of the generated .json file, just like the library does?
P.S I tried to dig in the library's calls without any luck
I believe that you will want to use the JWT library to generate an access token for OAuth 2.0 as stated in the firebase document on Use credentials to mint access tokens. The reason that you would likely want to use the library to mint access tokens is that in order to Make an authorized API call, you would need to create and sign a JWT using an algorithm like RSA256 to generate the signature to send to the server. This ensures that the request that is being set for a set time duration is being created by your service account only and not by some arbitrary service otherwise.
To generate a JWT claim for a server side application, you would need to request (specifically for fcm) you would need to generate a JWT request that looks like this:
{
"iss": ${YOUR_SERVICE_ACCOUNT_ID},
"scope": "https://www.googleapis.com/auth/firebase.messaging",
"aud": "https://oauth2.googleapis.com/token",
"exp": 1328554385,
"iat": 1328550785
}
An explanation of the claims data structure can be found here.
You would then want to compute and encode the signature using a UTF-8 representation of the claim like this:
{Base64url encoded header}.{Base64url encoded claim set}.
You then want to take that signature and make your request using it. The format would look like this:
{Base64url encoded header}.
{Base64url encoded claim set}.
{Base64url encoded signature}
and as an example from the site linked above, your specific request would look something like this:
{"alg":"RS256","typ":"JWT"}.
{
"iss": ${YOUR_SERVICE_ACCOUNT_ID},
"scope": "https://www.googleapis.com/auth/firebase.messaging",
"aud": "https://oauth2.googleapis.com/token",
"exp": 1328554385,
"iat": 1328550785
}.
[signature bytes]
You would then base64 encode this utf-8 string and send it along to https://oauth2.googleapis.com/token to mint a token using POST parameters of grant_Type (urn:ietf:params:oauth:grant-type:jwt-bearer) and assertion (your base64 encoded JWT from above with the signature).
This is a lot of work to do by hand and you will need to know the RSA using SHA-256 hashing algorithm to generate this (as its the only currently supported signing library), so that is why I believe Google recommends using the library as it does all this for you without needing to reimplement RSA signing or importing other signing libraries. The OAuth library that you linked in your gist above is for user OAuth, not machine or service account OAuth which avoids the Click to Authorize action. Service accounts, can't click to Authorize, so signing requests is a valid way to generate OAuth credentials without making long lived requests arbitrarily and ensuring valid requests. Sorry for the long winded response, but once I found the service account documentation, I got really interested :)
Related
I want to get a access_token to get information from Google Analytics API by passing it in the browser . I am not able to find the correct documentation anywhere. I have tried multiple ways but nothing seems to work. As of now, I got tokens via Google Analytics Query Explorer and it works for 60 minutes. I am looking for a permanent token or a token which is valid for a more period of time.
In order to access private Google analytics data you need to be authorized. In order to be authorized you use something called Oauth2
The initial request will look something like this. It will allow the user to consent to your applications access to their data
GET https://accounts.google.com/o/oauth2/auth?client_id={clientid}.apps.googleusercontent.com&redirect_uri=urn:ietf:wg:oauth:2.0:oob&scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code
Once the user has consented to your accessing their data, you will be given an authorization code.
Once you have the authorization code you can exchange it for an access token. This is a http post request.
POST https://accounts.google.com/o/oauth2/token
code=4/X9lG6uWd8-MMJPElWggHZRzyFKtp.QubAT_P-GEwePvB8fYmgkJzntDnaiAI&client_id={ClientId}.apps.googleusercontent.com&client_secret={ClientSecret}&redirect_uri=urn:ietf:wg:oauth:2.0:oob&grant_type=authorization_code
The response should then look something like this.
{
"access_token" : "ya29.1.AADtN_VSBMC2Ga2lhxsTKjVQ_ROco8VbD6h01aj4PcKHLm6qvHbNtn-_BIzXMw",
"token_type" : "Bearer",
"expires_in" : 3600,
"refresh_token" : "1/J-3zPA8XR1o_cXebV9sDKn_f5MTqaFhKFxH-3PUPiJ4"
}
The access token will work for one hour.
I recommend looking for a sample and a client library in your chosen programming language so that you dont have to do all this manually most of the libraries are designed to handle authentication and authorization for you.
I am trying to access https://api-crt.cert.havail.sabre.com/v3/auth/token from the postman with valid base64 encoded Authorization header.
What is the valid value for username? Isn't it same which I used for registration. Document showing it as EPR in form 'user-group-domain'. Please help
I am getting an error.
{
"error": "invalid_client",
"error_description": "Credentials are missing or the syntax is not correct"
}
Go to: https://developer.sabre.com/user/{YOUR_USER}/applications
There you'll see YOUR_USER's application
Your user is what you have below Client ID and the password is below Client Secret. On that you have: Base64(Base64(Client ID):Base64(Client Secret)) (this is generic, to show how it should be coded.
This will only work on CERT environment.
It may be obvious what I am going to talk about, but you must have a SABER GDS authorized user to use this service.
If you do not have an authorized web user you will not be able to make the service work.
Ask Sabre or the agency that you represent this user to access, because without this credential correctly released you will not be able to make any REST / SOAP services work.
You can download the postman functionality package from the link below:
https://github.com/SabreDevStudio/postman-collections
https://developer.sabre.com/product-catalog?f%5B0%5D=product_type%3Aapi_reference
I am Looking at the Network activity of this page: https://helm.csod.com/ux/ats/careersite/4/home?c=helm&lang=de-DE.
Specifically at the post request with the Name: "search". Its using an authorization token.
tldr: How is the following authorization token stored on the Client side?
Goal:
I would like to understand how the browser (client-side) stores this authorization token. I dont Need to get the data or know how to scrape with selenium or sthg. I would just be interested in the mechanics behind.
What i tried:
I find the token in the page source: view-source:https://helm.csod.com/ux/ats/careersite/4/home?c=helm&lang=de-DE.
It seems like there is an object csod created in /player-career-site/1.15.4/pages/home.js.
then the key is stored in csod.context.
Finally, csod.player.initialize(csod.context) is called.
Unfortunately, i failed digging in the Code and finding These function as there where too many Matches for initialize and my js are skills too bad.
As storage i am only Aware of the Cookies. It might be transformed / encrypted and stored in the cookies? But how is it then restored to the "original" token, before being added to the request Header?
This seems to be a CSRF prevent method.
The token is created with a key in the back end, it stores the original key in a session and sends the token to the client side.
When the client sends a request, the token is posted with the data as a header or with the data, then the back end gets the stored key in the session, generate the token with the same method and compare it with the posted token. If they are equal there is no problem, access granted.
It is not necessary to restore as you can't decrypt that depending on the algorithm (sha256, md5, etc)
And the browser don't do that, as it can be manipulated, there is no sense to.
The token sent here is JWT(JSON Web Token). This is a widely used standard authentication mechanism.
You can create your own token in any languages like JS, Java, PHP, Python, etc.
I am adding a basic authentication flow:
Let's say a user comes on a form. Enter his email & password.
Now an HTTP request is being sent to the server with credentials. The backend server checks the details and if successful, then returns a response containing the authentication token.
Most of the time this token is stored in localstorage and sometimes in cookies.
Now for every request the token is picked from the stored location and sent in the header.
On the backend, it is checked if the request header has the details or not. And then respond accordingly.
At last, whenever someone logs out then that token is removed from the front end.
I hope it helps! Let me know if you have any queries
I want to know the api endpoint where I can post username and password and that should return me the auth token. For more clarity I am attaching the screenshot.
I know it's making call to following endpoint but these endpoint are not having any documentation, maybe they are not public.
https://containerimages.azz.net/artifactory/ui/userProfile
https://containerimages.azz.net/artifactory/ui/userApiKey
The APIs you mention in the question are UI APIs. Those are not public and might be a subject to change. You should rely on them.
If you wish to generate a Docker config.json file as the one shown in the screenshot, the auth part is simply a base64 encoding of the <USERNAME>:<PASSWORD>.
For the part use can use:
An access token - this is the preferred method as tokens are revokable an expirable
API Key
Encrypted password
Clear text password
All options should be base64 encoded as mentioned above.
You can avoid storing the Docker credentials in the config.json file by using a credentials store as described in the Docker login documentation.
If you wish to get an Artifactory API key for a user, you should use the Get API Key REST API.
I'm implementing my own OAuth authentication system (with refresh_token support) for an app and I have some questions about how to do it:
Client identification: The client is registered in the auth server and gets a client_id and a client_secret. How do I generate it? is there some kind of relation between both values?.
User authentication: The client sends the users_credentials (username+password for example) + client_id and gets a refresh_token and (temp?)access_token. That access_token is the one I should use in further request or I should use a accesss_token`=F(refresh_token,access_token,client_secret). In the second case what does the F function consist on?
Access token refresh: The client send client_id, refresh_token and gets a access_token (and a optional new refresh_token). Does the access_token need the same conversion (whatever it be), as in the point 2?
If I'm wrong, when and how is the client_secret used?
Complete answers and concrete examples will be "bountied".
The authorisation/authentication server generates these values when you create an account with them (for instance when you create a developer account with Facebook or Google). If you are doing these parts yourself, they should be cryptographically secure pseudo-random numbers or letters. Remember that the client ID is usually publically visible, so choose a reasonably large set of alpha-numerics (I use 30 characters). The secret is private and can be harder to guess so I chose 30 digits with letters, numbers and symbols. These are not related to each other, it is just that one is public and the other isn't.
The usual way this works is that there is a browser redirect to the auth server passing the client id in the URL (and redirect uri) and specifically NOT the user id and password. The whole point of OAuth2 is that the client system never sees the user name and password, only the auth server. After this redirect, the auth server verifies the client id, checks the username/password (for instance) and then returns to the redirect uri with a temporary code. This temporary code is passed back to the Auth server in order to obtain an access token. Since this call is made as a POST from the server, it also passes the client secret to verify that it really is the correct client system and not someone who stole the client id from somewhere else. At this point, the auth server will return an access token (and optional refresh token - you do not need to use them, I don't).
If the client system wants to log the user in without them having to type in their username and password all the time, it can use a refresh token, if available, to call back onto the Auth server and if the Auth server is happy that the refresh token is still valid and any other business rules are correct, it can give you back another access token directly without the user being involved.
I recommend reading the OAuth2 spec here: OAuth2 Spec RFC6749. It can take a while but if you delete the bits you don't need and reduce the amount of data, there are plenty of useful examples in it.
FIRSTLY, The client identifier can be any string that you want, but it should be unique for each client. It can even be the client's choice if you wish.
The client secret should be a cryptographically strong random string. Here is how you could generate one in C#:
RandomNumberGenerator cryptoRandomDataGenerator = new RNGCryptoServiceProvider();
byte[] buffer = new byte[length];
cryptoRandomDataGenerator.GetBytes(buffer);
string uniq = Convert.ToBase64String(buffer);
return uniq;
SECONDLY, The whole point of OAuth is to allow external apps to do things on your behalf without asking for your credentials. So, you need to implement an authentication server that does the logging in part for you. The user opens the app and gets an option to Log in using your website. You tend out access tokens and refresh tokens once the user has keyed in his credentials. The app can then simply use the tokens to perform actions on the user's behalf. I wrote an answer to How would an efficient OAuth2.0 server / provider work? that explains how access tokens can be constructed.
Remember, the need for refresh tokens and the lifetime of access tokens purely depends on how you intend to use them and what does your security framework look like.
LASTLY, The refresh token can also be an HMAC encoded string/a JSON object as I had explained in the answer to the linked question. You can have random refresh tokens and a large backend storage to keep it to verify the tokens in the incoming requests, or have HMAC encoded strings for added security/less storage requirements/latency to decrypt/encrypt tokens.
Also, do make sure that you go through all the flows and possibly the RFC too as mentioned by Lukos.