Created a Swagger UI for APIs and wanted to expose the APIs using this Swagger(Means the app doesn't have any other UI set up other than this Swagger). Swagger has been configured for OAuth2 ClientCredential flow and it's token url is https://{{domain}}.okta.com/oauth2/{{OAuthServrID}}/v1/token, but while Authorizing, getting the below error
{error: invalid_client, description: Browser requests to the token endpoint must use Proof Key for Code Exchange}
I have seen few post regarding this issue like Okta introduced this requirement to prevent the client credentials flow from being used in web browsers. But is there a solution or workaround for this ?
Related
I have Keycloak for authentication and authorization of multiple applications (a web page and a REST API). From my understanding the flow for the web page when using OAuth2 authentication_code grant type is as follows:
In this flow, in the second step (the one in red) the resource owner logs in because she/he were redirected to the login page of Keycloak. This flow is clear to me and is working well.
But, with the REST API I don't know what is the process to authenticate and authorize the user (resource owner), because there isn't a browser to redirect him to the login page of Keycloak. So, I tried with the password grant type and it worked, but then I realized that this grant type is deprecated. So I tried again with the authorization_code grant type but can't make it work. I am trying to get the token using the following request:
URL: http://localhost:8080/auth/realms/somerealm/protocol/openid-connect/token
Body:
username: someuser
passwoord: somepassword
grant_type: authorization_code
client_id: someclient
secret: somesecret
The problem is that I am receving the following response:
{
"error": "invalid_request",
"error_description": "Missing parameter: code"
}
I know I have something wrong in the request (and in my understanding of OAuth2), but I have read a lot and can't discover what it is.
API (backend) doesn't need any login flow usually. It just needs to verify token and then it executes requested operation or it denies it (response code 401 - problem with authentication / 403 - problem with authorization). It doesn't redirect to auth server.
Client, which is using API must obtain token before API request. It can be done by the frontend (e.g. SPA with The Authorization Code Flow + PKCE) and then frontend maintains state (token refresh, error codes from the API, ...).
If you don't have any frontend, then procedure how to get token must be part of API specification. For example see swagger doc: https://swagger.io/docs/specification/authentication/oauth2/
The Client credentials flow should be used machine to machine authentication, so it's not a solution if you need to know user identity.
With the authorization_code grant type you have to spawn a browser in some way.
password is unfortunately deprecated, but the recommendation is to use client_credentials for these cases now. I hope this decision get reversed before OAuth 2.1 is released.
I`m new to OAuth 2.0 and am trying to develop a application using a third party OAuth provider with Authorization Code grant flow as ny Authorization Server and Spring Security.
This provider gives me two endpoints /authorize and /token and those two, after the user authorizes its access, will return a access token.
So far, I have secured the "/" endpoint, so the application redirect the user to the authorization page and then, in the callback endpoint, store the token so it can be validated by a filter in each request.
But, as the application is mainly a set of REST API's, we want to be able to test it using Postman, with that said, on Postman, I am getting the token by setting the Authorization as OAuth 2.0 and requesting the token directly from the third party endpoints but, as Postman have its own callback URI, my application doesn`t store the token generated.
So, my two questions on this are:
Using /callback endpoint to store the token and validating it before each request by a filter is the common way of doing it?
To use Postman, should I create an endpoint for storing the token generated outside the application context or should I create an Authorization Server of my own as an additional layer on top of this third party AS?
Since your application is a set of REST API's, you need to make it as a Resource Server (in terms of OAuth2).
Resource Server doesn't perform authentication itself, it only validates a token from Authorization header (Resource Server in a nutshell).
You can find an example in Spring Security samples: oauth2resourceserver
I eventually come to the conclusion that I was using Postman wrong the whole time.
So, by the end, we got the Token saved on the database when the user logs in and, then, return it to the caller, whether it is the Front-end application, or Postman itself.
Then, in every call to the API's, the caller should include the token as Authorization on the header and a Filter on Spring will check the token against the Database.
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 am building an Angular SPA app and using Okta as an Idp. since its an SPA so I think I need to use Implicit flow. I have two queries here-
Since in Implicit flow a refresh token is not issued, does it means that th user will be logged out of the app after the token expires and he has to log in again?
Why do I need to use Implicit flow in case of SPA? why not Authorization code flow? since I have control over both the front end (SPA) and back end (REST API) . for example in case of Spring MVC architecture for the web app Authorization code flow is possible.
Thanks,
pchh
Yes, if the token expired, you have to re-autenticate. Normally you still have a valid session on the identity providers site, so you can do a "silent" login using an iframe. Libraries like oidc-client support a silent login, which can do this for you.
You need to use implicit (or hybrid) flow, when you need to access to the access token from your javascript app. With authorization code flow your javascript app doesn't get the access token, so if your API needs an access token for authorization, what are you going to send?
If your auth server supports OpenID Connect (OAuth2 extension) and single sign-on (SSO) feature, to get a new token before the old gets expired, use an iframe with a URL you used for authentication, but add prompt=none parameter (and possibly id_token_hint parameter). See OpenId Connect RFC. The prompt=none parameter tells the /auth endpoint to issue a new token(s) if the user has an open SSO session at your OAuth2 server. If not, the request will fail. There is a separate RFC for session management.
The Authorization code flow requires you to access the /token endpoint, which usually requires authentication (client ID + client secret) and you cannot keep the secret safe in a browser. For this reason, the token endpoint doesn't use to support CORS headers, so you cannot access it using XHR. Using the Auth code flow, you get a code as a redirect URL param (?code=), which gets to the server hosting your SPA (browser sends it there after redirect). The implicit flow returns tokens in hash part of the redirect URL (#access_token=), which stays in a browser (it's not sent to the server), so it's safer.
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