Is Jenkins has token mechanism to authorize Jenkins APIs without using username?
Thanks,
Srikanth.
Token without password supported since version 1.426
API token is new since 1.426
The API token is available in your personal configuration page
Specifying the real password is still supported after 1.426, but it is not recommended
Related
I am exploring possible solutions for creating something like "API Keys" to consume my API. The goal is to allow for users to generate one or many "API Keys" from the web app and use the static generated key from the CLI app.
The web app and the client app are already using standard OIDC with JWT tokens for authentication and authorization using RBAC (role-based access control). The CLI app can already authenticate the user through the standard browser flow (redirects the user to the browser to authenticate and exchange the token back to the client).
The "API Keys" solution I am trying to achieve should have some fine-grained options where it won't authenticate as the user, but will authorize the client on behalf of the user (something like the GitHub Personal Access Token).
To me it seems like a "solved problem" as multiple services provide this kind of feature and my goal is to do it the most standard way possible using the Oauth2/OIDC protocols but I can't find details on what parts of the protocols should be used.
Can anybody provide any guidance on how it is supposed to be done using the Oauth2/OIDC entities?
Can I achieve it by only using Role-based access control or do I need Resource-based access control?
It went through the path of creating a new client for each "API Key" created, but it didn't feel right to create so many clients in the realm.
Any guidance or links to any materials are appreciated.
Can anybody provide any guidance on how it is supposed to be done
using the Oauth2/OIDC entities?
OIDC is based on OAUth 2.0 so after user login you have id tokens, access token and refresh token on the backend side. To generate new access token without asking user for authentication data you should use refresh token: https://oauth.net/2/refresh-tokens/
Can I achieve it by only using Role-based access control or do I need
Resource-based access control?
resource-based access control is more flexible solution here, but if you business requirement is not complex, then role based might be enough.
It went through the path of creating a new client for each "API Key"
created, but it didn't feel right to create so many clients in the
realm.
It is one application so you should use one client with specific configuration for access token and roles/permissions for users.
Update:
We can use GitHub as an example:
User is authenticated during login
for OIDC code is exchanged for id token, access token and refresh token
session for user is set for web browser
User can request access token
in GitHub authenticated user can request github.com/settings/personal-access-tokens/new endpoint
request is accepted, because user is authenticated based on session
backend service responsible for returning access token can obtain new access token using refresh token from point 1.
access token is returned to GitHub user
To call your API in an OAuth way, CLI users must authenticate periodically. Resulting access tokens can be long lived, as for GitHub keys, if you judge that secure enough. The access token returned can be used exactly like an API key. There may be a little friction here between usability and security.
CONSOLE FLOW
The classic flow for a console app is to use the Native Apps Desktop Flow from RFC8252. This involves the user interactively signing in using the code flow, then receiving the response on a loopback URL. It is an interactive experience, but should only be required occasionally, as for GitHub tokens.
API KEYS
The access token returned is sent in the authorization header and you can use it as an API key. Access tokens can use a reference token format. to make them shorter and confidential, to prevent information disclosure. These will be more natural in a CLI.
API AUTHORIZATION
When your API is called, it must receive access tokens containing scopes and claims, to identify the user. This will enable you to authorize correctly and lock down permissions.
{
sub: 586368,
scope: repos_write,
topic: mobile,
subscription_level: silver
exp: ?
}
TOKEN REFRESH
Sometimes CLI access tokens are long lived, for convenience. A more secure option is for the CLI to use token refresh. It can then store a refresh token in OS secure storage, then renew access tokens seamlessly. My blog post has some screenshots on how this looks, and a desktop app that does not require login upon restart. The CLI needs to deal with expired access tokens and handle 401 responses.
DYNAMIC CLIENT REGISTRATION
Some developer portal scenarios use DCR. It is another option in your security toolbox. It could potentially enable a silent client per CLI user:
User runs a standard authentication flow with a DCR scope
This returns an access token that enables client registration
The resulting token is used to register a new client
This could potentially be a client ID and client secret used in a CLI
Afterwards, the user and client are bound together. Probably not immediately relevant, but worth knowing about.
We have Duende server for our UI and users provide their username and password and obtain an access token that is then used by our SPA app to call api's with the access token issued by our identity server.
I'm in a situation where I need to call the same API from a script and was wondering if RestSharp has some capability to obtain an access token if provided certain information (perhaps the users email/password etc that are typically entered into an interactive website) ?
I see that the RestSharp has some OAuth related "authenticators" but the documentation is unclear exactly what they achieve. I also dont see it mentioning anything about an email address and password.
I'm wondering if theres an option that is different than me generating a JWT elsewhere and supplying it directly to restsharp. I'd love if there was a programmatic way to generate the token directly from the IDP.
RestSharp documentation doesn't make it secret about how authenticators work. Both OAuth2 authenticators only add the necessary header or query string using the token you provide, but they don't request the token.
Duende server documentation explains in detail how to get a token based on the password grant (which is using the username and password).
Although the OAuth2 spec is stable, each API vendor has its own limitations. For example, Twitter API v2 only supports the client_credentials grant type. Therefore, it's not easy to create a generic OAuth2 client.
Still, it's quite easy to amend the Twitter authenticator sample from the docs and extend both request and response models to support the Duende server token request endpoint.
We are running an application via Remote Desktop Services. The application authenticates to our web api middleware running in under WCF using Negotiate and Windows Auth.
We now have a scenario where the middleware needs to make calls to another service and pass a bearer token so that it can run as the user who made the initial request. It would also enable us to not have to use Negotiate on every request, which is fairly expensive.
We're looking for a way that we can make a OAUTH grant_type = client_credentials, but using the credentials of the user which is authenticated via Negotiate to our middleware. I haven't seen any examples of how that would be done. All of the examples I see pass the users credentials via client_id and client_secret, or in the HTTP Basic Auth header, but no examples of grant_type = client_credentials, where the credentials are via Negotiate.
Getting a token as the user without the user interactively logging in via OAuth is generally not supported since the password is unknown.
Aim for option 1 below:
Use client credentials, then pass the user id in addition via a different parameter, such as a path segment - simplest option is to get the downstream service to support this
Login via OAuth and federate to an Identity Provider that uses windows auth - this is likely to be a very big migration job - though it is the preferred way to use OAuth with Windows auth
My authentication calls an API of the other server, I don't have a database table(The username and password does not exist on my server).How do I use JWT authentication in this case?
Thanks.
When You try to implement your own authentication server, you have to have a database with the username and passwords.
But after the user has its JWT Token, it can authenticate itself with it to your API Server, as long as the expiration time has not passed and the signature secret is shared between your auth and API Server, since you need to check if an attacker might have modified it.
After the expiration time has passed your client needs to issue a new token. You would usually use a second refreshToken which has a longer expiration time, and is checked against a DB to issue a new accessToken.
You could implement this yourself, but I would highly advise you to use technologies like OAuth2 since OAuth is used across all major brands like Google, Twitter, Github etc and is well tested against vulnerabilities.
I have built my own REST API with Symfony2. To query this API, user have to authenticate himself with OAuth protocol (three legs flow).
Now, I'm going to develop the front office based on a Angularjs app and I want to use my own Rest API from angularjs. What's the best way to login users to my api from the front office and fetch a token ?
I dont want users have to authorize my own app.
Does the three legs flow is really adapted for this case ? Maybe is better to support xauth authentication with a username/password login ?
Ok after some research, it seems that the most easy way to manage login/authentication between JS client and Symfony2 backend is to use password grant type (thanks #ricoux) which allows user to get a token with an username/password, like this:
http://host.com/oauth/v2/token?grant_type=password&username=Bat&password=test&client_id=clientidkey&client_secret=clientsecretkey
With fosoauthserverbundle, you need to set allowed grant type when you create your client:
$clientManager = $this->container->get('fos_oauth_server.client_manager.default');
$client = $clientManager->createClient();
$client->setName('ApiTest');
$client->setRedirectUris(array('URL' => 'http://callbackurl.com'));
$client->setAllowedGrantTypes(array('token', 'authorization_code', 'password'));
I try to do exactly the same thing : REST API with symfony2 and a javascript client with angularjs...
As Nisam said, FOSOAuthServerBundle is the best bundle to integrate OAuth2 authorization server in your symfony2 app.
I your case, if you don't want users have to authorise your own app, maybe a client with password grant type is the solution. In theory the password grant type can be used to exchange a username and password for an access token directly, but I never experiment it with FOSUserBundle, and I find no example in the doc.
When you ready to use third party bundles, FOSOAuthServerBundle is one of the best solution