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.
Related
I am learning to connect to one of our 3rd party's API, and the first step in doing so is to first get an access token to use for additional requests.
To get that access token, I send a POST request that includes an API key in the header, along with the username and password in the body (as JSON). And that successfully returns a token.
But how do I set up that up in a collection? In postman I have options of API token, Basic Auth, Oath2, etc. But I do not see how you set up and include both the API key and user/password.
I've tried different scenario's of just the API Key and Oath2 with credentials, but unsure how you set it up to include both.
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 :)
A client wants me to integrate his News from LinkedIn to his TYPO3 site.
Yes, I am one of more admins of the company page on linkedin, the app is verified by the client.
I have client_id and client_secret
When i do the request to get an accessToken, something like:
https://www.linkedin.com/oauth/v2/accessToken?grant_type=client_credentials&client_id=&client_secret=
the answer is
error "access_denied"
error_description "This application is not allowed to create application tokens"
I have no clue, what the necessary permissions are and where to set them.
Neither the linkedin backend nor the developers shows up with any proper link.
I know, this question has been asked before, but its about the permissions.
Please set me on the rail...
You are trying to use the 2-legged OAuth process which is by "client credentials" unfortunately that process is not available by default to all applications which is probably why you are receiving that message.
This is mentioned in the first paragraph of the documentation of the 2-legged OAuth process.
Your application cannot access these APIs by default
https://learn.microsoft.com/en-us/linkedin/shared/authentication/client-credentials-flow?context=linkedin/context
Your application needs access to enterprise linkedin products that can perform API requests that are not member specific in order to be able to use that process.
By default the application only have access to the 3-legged process which involve a GET https://www.linkedin.com/oauth/v2/authorization before making a request to get access tokens.
More information about the 3-legged process can be found here
https://learn.microsoft.com/en-us/linkedin/shared/authentication/authorization-code-flow?context=linkedin/context
I use the .net Packages CodeHelper.API.LinkedIn
.NET
using CodeHelper.API.LinkedIn;
LinkedInHelper _helper = new() {AccessToken = "{ACCESSTOKEN}" };
string _id = await _helper.GetAuthorID();
CURL
curl -H "Authorization: Bearer "
"https://api.linkedin.com/v2/me?projection=(id)"
More Information
CodeHelper.API.LinkedIn
Nuegt Pakcage
Im getting some 403 errors in some HERE position requests. Looks like that the servers are not synchronized.
My Account was created 2 weeks ago.
{"error":{"code":403,"description":"These credentials do not authorize access. Please contact your customer representative or submit a request here https://developer.here.com/contact-us to upgrade your account. You can also get valid credentials by registering for a free trial license on https://developer.here.com.","message":"Forbidden"}}
First, generate apiKey and bearer token in your here account. For the apiKey go to your profile, create a new app and then you can generate it under Credentials -> API Keys.
For the bearer token, you first need to create oauth tokens (under Credentials -> OAuth), download the credentials.properties file, then use their CLI to generate the bearer token. Before you can use the CLI, you need to install it and then set it up.
I'm on a mac, so for me this installed it:
$ brew install heremaps/olp-cli/olp
Follow instructions on their page for whatever OS you have. Now you are ready to generate the bearer token. Make sure you are in the same directory where you downloaded the credentials.properties file earlier:
$ olp credentials import default credentials.properties
Generate the token:
$ olp api token get
Now you have everything to do a call to their API (replace HERE_API_URL with the one you want. They have many different ones for various use-cases):
GET
https://{HERE_API_URL}?apiKey={YOUR_API_KEY} -H 'Authorization: Bearer {YOUR_TOKEN}'
Note: Do not use app_code and app_id. These have been deprecated.
I had the same issue when I had only one API key created. Once I created a second API key, the issue went away.
Make sure you have two API keys generated, even if you only use one. The documentation suggests setting two keys but it never mentions it's required.
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.