I have an API secured with bearer tokens issued by IdentityServer.
Some applications use client_credentials flow (which requires a client_secret), and a web UI uses authorization_code (with PKCE) (which does not require a client_secret.
On the swagger page in the authorization modal the client_secret text box is either present for both cases or absent for both cases according to whether I
.OAuthUsePkce();
in UseSwaggerUI.
Can I get both flows to work or does it have to be one or the other?
Related
Per the new security guidelines at https://oauth.net/2/grant-types/implicit/, the implicit flow is not recommended. Since ADAL.js uses the implicit flow, will it be affected and is it recommended to use ADAl.js implicit flow for new applications?
Yes, I agree that as per the new guidelines, the implicit flow is not recommending. Currently, ADAL js uses the OAuth 2.0 implicit flow and it does not return refresh token for security reasons(refresh tokens have longer lifetime than access tokens and are therefore more dangerous in the hands of malicious actors).
It is designed to return an ID token when the resource for which the token is being requested is the same as the client application. When an ID token is returned, it cached by the library.
So when we use authenticationContext.acquireToken(resource, callback), it allows the application to obtain tokens silently without prompting the user again. ADAL js uses a hidden Iframe to make the token request to Azure AD.
But to use PKCE flow, we can make a http post call to https://login.microsoftonline.com/tenant_id/outh2/authorize endpoint by passing code_challenge along with other parameters in the body and gets the authorization code. And use that code and make a call to https://login.microsoftonline.com/tenant_id/outh2/token endpoint by passing code_verifier along with other parameters in the body and gets the token.
If you are using SPA, and have no backend components or intend to invoke a web API via JavaScript, use the OAuth 2.0 implicit grant flow.
But if you have a backend component and you are consuming an API from the backend code then implicit flow is not a good fit. In that case you can use OAuth2.0 auth code grant flow or OAuth2.0 client credential grant flow, it provides the ability to obtain tokens that reflect the permissions assigned to the application itself.
I have done a sample application using Sprint Boot, Spring security and JWT and define my custom authentication & authorization filters. While performing basic authentication (passing username & password) I get JWT token in the format of xxxx.yyyy.zzzz where xxxx is header, yyyy is payload and zzzz is signature and each part is encoded using Base64URL encoder. What I do not understand is how JWT is different from OAuth 2.0. In OAuth 2.0, we can pass 2 types of grant_types as either 'username' or 'client credentials' & also needs to pass client id, secret id to get access & refresh tokens.
Please assist to clarify my following doubts:-
1) Is JWT lighter than OAuth 2.0 as it does not contain the refresh token but just access token?
2) Is JWT cannot be used to make a standalone authorization server like we can make a standalone authorization server using #EnableAuthorizationServer annotation when it comes to OAuth 2.0. Is my assumption correct?
3) JWT does not accept client id/secret client but just used as basic authentication to get bearer tokens?
4) Is the format of access token (or bearer) for both OAuth2.0 and JWT are different?
I have seen an example where both OAuth 2.0 and JWT were used. OAuth 2.0 was to make authorization server which returns JWT token only in the end but did not understand why JWT was used if OAuth2.0 can return a token by itself.
Thank you
JWT is a JSON-based token defined in RFC 7519. OAuth 2.0 is an authorization framework defined in RFC 6749. Comparing both is like asking "How Glucose is different from Apple Pie?".
However, it is possible to bring OAuth 2.0 and JWTs together as is defined in RFC 7523 – The JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. It standardizes, how to use JWTs as bearer tokens within the OAuth 2.0 framework, which enables what I call stateless authentication.
Regarding your questions:
Whether or not you use JWTs as bearer tokens does not influence whether or not you want to hand out refresh tokens.
Not sure whether I get your questions. However, using JWT allows you to do decentral, stateless auth decisions as there is no necessity to store token state centrally. However, nobody prevents you from having a standalone authorization server.
How you want to do authentication has nothing to do with JWT. It is still OAuth 2.0.
In OAuth 2.0 bearer tokens are considered to be opaque tokens – the format does not matter. If you use JWTs as bearer tokens, you need to follow the corresponding RFC.
I have configured my client to use Hybrid flow with a grant type of password and offline. The user is able to generate an access token and the response does include a refresh token.
My question is I do not see documentation on how to use the refresh token for non .Net environments. Specifically I am curious if any body has a sample refresh flow in another language or Postman that shows which endpoints to hit and what the request needs to look like when the user requests a new token via the refresh token.
Thanks in advance,
G
This is documented at http://docs.identityserver.io/en/latest/endpoints/token.html
The token endpoint can be used to programmatically request tokens. It supports the password, authorization_code, client_credentials and refresh_token grant types). Furthermore the token endpoint can be extended to support extension grant types.
Example
POST /connect/token client_id=client1&client_secret=secret& grant_type=refresh_token&refresh_token=hdh922&redirect_uri=https://myapp.com/callback
I'm currently trying to implement the OAuth 2.0 authorization code grant on a public client/native client (Android App).
Since it is impossible to store the client_secret on the device, I wanted to use this grant type with rfc7636 / Proof Key for Code Exchange by OAuth Public Clients (PKCE).
I'm using wso2 5.3.0 IAM in the backend.
The Authorization step works perfectly fine, but I'm not able to get the Access Token without a client_secret: invalid_request, Missing parameters: client_secret
Did I misunderstand the authorization code grant with PKCE wrong or did I miss some configuration in the IAM?
In comparison: It is possible with auth0.
Best Regards,
Robert
Even if you use the authorization code flow, client_secret is required at the token endpoint if the client type of your application is confidential. "4.1.3. Access Token Request" in RFC 6749 says as follows:
If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.
So, change the client type of your application to public. I don't know WSO2, but I guess that it provides settings menu to switch the client type like below.
(screenshot of Authlete's web console)
The definitions of confidential clients and public clients are described in "2.1. Client Types" in RFC 6749.
Yes, the client_secret is mandatory in WSO2 IS implementation due to the Apache OLTU library that has been used internally to implement the OAuth2 feature.
Currently there is no way to register an application as a public client as explained.
However that doesn't mean there are necessarily any security pitfalls. Basically what the recommendation says is, not to embed the client_secret in a mobile app, because it makes it vulnerable. It doesn't provide any additional security for protected backend resources, because the client request is anyway not authenticated using client_secret. If you just treat the "Base64(client_id:client_secret)" as one single string it doesn't make any difference in the protocol or security of the protocol.
So when using WSO2 IS with mobile applications, following recommendations need to be followed.
Use authorization code grant type, which requires the client_secret.
Use PKCE (after WSO2 IS 5.2.0)
If you have other type of clients or channels for the same applications, e.g. like web, then register them as a separate service provider in IS and generate a separate pair of client_id, client_secret for them.
Disable "client_credentials" grant type for the particular OAuth2 mobile client you register in WSO2 IS, so that those apps can't get an access token without user authentication.
Going one step further, if you need to have unique client credentials for each instance of the mobile applications then use OAuth2 Dynamic Client Registration (DCR) to generate client credentials on the fly.
By following above 5 recommendations, it gives you the same level of security as recommended in the specification.
For Authorization grant flow you can send the request with empty client_secret. Try putting empty string like this client_secret='' and it should work as expected. You cannot request TOKEN_URI without client_secret parameter.
PKCE is used to protect theft of authorization code, Authorization code is valid for 10 minutes, when auth code is redeemed for access_token we also send code_verifier to make sure the auth code is not stoled by someone. code_verifier and code_challenge are generated together and code_challenge is used while requesting for auth code & code_verifier is used while requesting for access_token
In OAuth 1.0, 2-legged is pretty easily: Simply send the request as usual and omit the access_token header.
Things seems to have changed in OAuth 2.0 (drastically, as I found out today :)). In OAuth 2.0, the request no longer has headers such as the nonce, consumer key, timestamp etc. This is just replaced by:
Authorization: OAuth ya29.4fgasdfafasdfdsaf3waffghfhfgh
I understand how 3 legged authorizations work in OAuth 2.0 and the application flows. But how does 2-legged work in 2.0? Is it possible to design an API that can support both 2-legged and 3-legged OAuth 2.0?
I have been searching for information regarding this, but I have been finding a lot of stuff on 2-legged for 1.0 and almost nothing for 2.0.
After lots of research, I discovered that client_credentials grant type is for this scenario. Once you punch this term into google, you can find loads of very helpful resources.
This is the normal flow for 3-legged OAuth 2.0 (we want the user to sign in):
Assume we have the following endpoints in our app for authentication:
/oauth/auth
/oauth/token
Normally (for authorization code grant), we direct the user to /oauth/auth?state=blah&client_id=myid&redirecturl=mysite.com/blah
Then upon authentication, the user is redirected to mysite.com/blah?code=somecode
We then get somecode and exchange it for a token using /oauth/token?code=somecode&client_id=myid&client_secret=mysecret
We can then use the token to make calls.
This is the application flow for client_credentials to implement 2-legged OAuth 2.0, which is markedly simplier:
In this approach, we do not need to perform any authentication.
We simply POST to /oauth/token with the following form data:
grant_type=client_credentials&scope=view_friends
Note that scope is optional. The endpoint then directly returns an access token for us to use (no refresh token is provided). Since no refresh token is provided, when the token expires, you will need to reauthenticate and ask for a new one.
This leads to the following caveats:
Use this only for (very very) trusted applications such as internal applications.
You need to devise your own way to authenticate. For instance, the RFC's example uses basic auth.
Another solution is to use JWT (JSON web tokens) like the google OAuth API. It is a very complicated process, but there exists numerous libraries for generating your JWT. You then post the following form data (url encoded of course):
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=generated_jwt
This is posted to /oauth/token to get your token.
As for the question of whether you can create an API that supports 2-legged and 3-legged OAuth 2.0, Yes, it is possible.
Then /auth endpoint is only used when users need to authenticate against the service.
In the /token endpoint, simply check the value of grant_type in the GET parameters for urn:ietf:params:oauth:grant-type:jwt-bearer if using JWT or client_credentials for client_credentials.
Note that when generating the client_id and client_secret to give to the user, if you are supporting multiple grant_types, ensure that you have a database column to store what type of grant type the id and secret was generated for. If required to have multiple grant types per user, generate a different set of credentials for each grant type.
You can also check out Google's implementation of 2-legged OAuth2 (I believe this documentation has been published only recently).
The Google Drive SDK delegation docs should also help understanding Google's 2-legged OAuth2 implementation.