Try to use oAuth authorization flow. I get interface with requesting access to account in express gateway UI.
Can I tune flow so that this interface is skipped and all requesting scopes was approved by default?
You surely can, but you will have to clone the source code and change the html code directly from there. Unfortunately we have no way to use a plugin to change the page
Related
I am planning to create a single page web application and all user authentication would be handled by AWS Cognito. By reading through some of articals, they all suggest using "code" grant flow + PKCE rather than implicit flow since implicit flow is deprecated in OAuth 2.1
I created a test user pool with AWS Cognito, by using Postman I successfully get access_token, id token and refresh token with code grant flow + PKCE.
I double checked with AWS Cognito Doc, seems refresh token will always be returned if using code grant flow and I cannot find anywhere in AWS console to disable returning refresh token. So just wondering how can I protect refresh_token? Cookie or localStorage can not stop XSS.
It is usual to route requests for tokens via a backend, eg a utility API, which also represents the refresh token as an HTTP Only SameSite=strict encrypted secure cookie. See this crypto code for an example.
The backend component also enables you to use a client secret, in addition to PKCE, which improves security a little. Cognito supports this, so I'd recommend using both.
BEST PRACTICE
OAuth for browser based apps recommends this approach. Stakeholders often expect you to be using the backend for frontend described, and it will make life more comfortable if you have to explain your app's security.
XSS
With the above HTTP only cookie approach, malicious code would not be able to steal your refresh tokens, and this is therefore the recommended way to handle them.
If your SPA has XSS vulnerabilities, then malicious code might be able to steal your data though, regardless of whether tokens or cookies are used to access data. Therefore it is critical to implement XSS protection carefully, regardless of your OAuth solution.
I have an API that I have setup in WSO2's API Manager Publisher tool. All the calls work fine when called correctly with an Access Token.
But I have one url that I want anyone to be able to call. (It is a customized Swagger UI page (different from the one built into the WSO2 tooling).)
To do this I add the Swagger UI url as a resource. But when I go there it says:
Required OAuth credentials not provided. Make sure your API invocation call has a header: 'Authorization : Bearer ACCESS_TOKEN'
Generally, I really like this default. (I want all my other API resources to require an Access Token.) But for this one I don't have an access token and don't expect to.)
Is it possible to publish one resource and not need any authentication?
Also it can be done in 2.x versions of API Manager through disabling for each endpoint the security in publisher tool. In manage tab, resources section, for each resource/endpoint set the value x-auth-type to "None". Default value is "Application & Application User". This disable security and then authentication required for accesing to the selected API resources.
This can be done as mentioned in https://stackoverflow.com/a/61133046/3176125
Basically you can turn off for one of the resources while you allow security for the rest of the resources.
In Angular/.net core 3.0 app I am using Azure AD implicit grant flow. The Web API uses authorisation and allows access based on roles (e.g. SuperAdmin, Admin and User roles etc). I need to write automated integration test for the Webapi (I can use a seperate client app too for testing). Any ideas which will be the appropriate grant flow for testing. I have read about ROPC flow (Resource ownder password credentails) flow and its not recommended to be used. I can't use client credentails flow as this wont work with Authorisation. I will appreicate any links or examples.
1.You should send a login request first(To enable the implicit grant flow, select the tokens you would like to be issued by the authorization endpoint…)：
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?client_id={your client id}&response_type=id_token&redirect_uri=http://localhost:8080/login/oauth2/code/azure&scope=openid&response_mode=fragment&state=12345&nonce=678910
2.Getting access tokens silently in the background:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?client_id={your client id}&response_type=token&redirect_uri=http://localhost:8080/login/oauth2/code/azure&scope=https://graph.microsoft.com/user.read&response_mode=fragment&state=12345&nonce=678910&prompt=none&login_hint={your-username}
3.You can also refer to the following documents, hope to help you：
https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-v2-angular
Just if it helps someone, I did not find an alternate to get an access token to call the webapi which uses role based authorization (i.e. allow access to only users in certain AD groups) for my integration tests. So created few test users in the relevant AD groups and used resource owner password credential flow to get the access tokens and called the web api
I've built a JHipster application with oauth2 authentication. The latter is implemented by Keycloak through the generated docker-compose file.
Everything works fine in the browser for "human" users. But I need to make some external programs use the API while beng authenticated.
So I started to simulate direct access to API with Postman. I read about XSRF-TOKEN cookie. But to be frank, I don't understand the process of authentication.
Can anyone explain how to perform authenticated requests to the JHipster API regarding keycloak ?
Maybe it isn't the appropriate approach : I also read about implementing a Configuration based on another authentication mecanism, that should be used for controllers exposed on a different endpoint.
Any help figuring out all of that would be really appreciated !
You need machine to machine authentication. Generally Open ID Connect (OIDC) offers client credentials flow for this case. So in theory you just enable it in the Keycloak client configuration and you may use it. But it depends on your API auth implementation. Your API very likely uses different OIDC flow for humans and it may not be ready for client credentials flow.
I got it working: Jan's tip show me the way.
Mainly I followed this tutorial.
The solution would be to add a client configured with Standard flow, Service account and Authorization enabled. Then I added the JHipster client scope provided by the generated docker-compose setup.
Once that was configured, I configured the request to use the Oauth2 authentication. I filled the configuration form for token request according to the tutorial. And I was good to go !
Many thx !
I have a backend running Django 1.7 and a front-end developed separately with Bootstrap. The front-end talks to the backend through a REST API that I want to protect with OAuth2.
The question is: which grant type should I use? I trust the people working on the front-end but it does not mean I trust Javascript :-) I can't decide whether I should choose the Implicit grant or the Resource owner password-based.
Any experienced advice?
Especially when working with an API that is not on the same domain or server as your front end, it's usually better to use something like the web application flow for OAuth 2. This is typically referred to as the implicit grant, and uses the grant_type of token.
This way you won't need to worry about sending credentials across the wire, like you would need to for the resource owner password credentials grant. Along the same lines, you also don't have to deal with hiding private keys for the authorization code grant.
With the implicit grant, only the OAuth token must be stored on the local machine. This should be better, as the token should be able to be revoked quickly in the event that the token become public or something else forces it to be invalidated. The user should be logged in on the API server when the authorization request is made, but most OAuth providers support a custom login page that can be used as well.
With the password credentials grant, both the username and password must be stored on the local machine which requires you to additionally secure them. They are also considerably more difficult to revoke if the need arises.