I am using a custom authorization server using Spring. When hitting my protected resource on the client, I am successfully redirected to the auth server. I log in and get the OAuth approval page. Once I authorize the scopes, I am redirected back to my client app with a URL such as:
http://myapp.com/login?code=UjG0wC&state=POez9N
I get that this is the authorization code and it can be exchanged for a token. However, I am having trouble finding examples of how to do this. Do I need to write code to now go and request the token from the auth server, or is there a configuration piece that I am missing? Would it be better to focus on switching to the implicit grant type?
I was missing an AuthorizationServerConfigurerAdapter, which needed to include allowFormAuthenticationForClients()
Related
I went thru multiple posts saying how implicit grant is a security risk and why auth code grant with AJAX request to Authorization server should be used after redirecting to application (without client_secret passed to Auth server).
Now in 2019 there is no CORS issue as I can allow app domains on authrization server.
I have following concerns
If I use implicit grant:
Now implicit grant has security issues as Authorization server redirects to application server with token in url.
If I set expiration time to 5 to 10 minutes, after expiration, user will be redirected to login and its problematic especially if he is filling up important form on application. What to do in this scenario? Note that there is no refresh token in Implicit grant to update with new token, so refresh token is out of the picture.
If I use Auth code grant:
Suppose if I hit AJAX request after getting redirected to my main application site, and get token in exchange of code,
Auth code grant uses client_secret. And in javascript app where anyone can see the code, we cant use secret.
Assume now if I dont use client_secret. There are multiple sites that use auth server say site 1, 2, 3. Now if we say dont use secret, anyone can make host entry in nginx server that will have my site's domain name but his own IP address. In this case host injection is the issue. How to deal with it?
What approach should be taken here? I am more inclined towards auth_code for SPA but the issue is how to deal with client_secret?
Thank you for reading.
There are multiple links that recommends use Auth code grant instead of SPA. A few out of multiple links :
https://www.oauth.com/oauth2-servers/single-page-apps/
https://medium.com/oauth-2/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926
You've already linked references that make it clear that you should NOT use implicit grant in an SPA. Your confusion seems to come from your assumption that the code grant flow requires use of a client secret, but that is not the case. A SPA, like any browser or device app, is (should be) a PUBLIC client, and cannot be trusted with a secret. Therefore, it does not use a secret. The client secret is suitable ONLY for use with private clients, which is to say, server-side code calling the auth api.
the 2019 recommendations are to use a PKCE variation of the Authorization Code Flow that does not need a client secret:
https://brockallen.com/2019/01/03/the-state-of-the-implicit-flow-in-oauth2/
There's some write ups and code samples on my blog that might be useful to you - I updated this one on messages recently:
https://authguidance.com/2017/09/26/basicspa-oauthworkflow/
With LinkedIn's planned deprecation of their JS SDK, is there any way to complete the OAuth2 flow and obtain an access token from the client-side, without using a server-side proxy to exchange the auth code for the token?
According to this SO post, LinkedIn does not allow for an implicit grant flow. It's from 2015, but appears to still be relevant.
Is there any alternative way I can obtain an access token for a user who authenticated with LinkedIn, without hitting a self-hosted proxy? My application only needs basic profile data for the user.
Edit
To provide more context, the error I receive when making the second request to https://www.linkedin.com/oauth/v2/accessToken is No 'Access-Control-Allow-Origin' header is present on the requested resource. The same request made from postman works fine and returns the access token. I understand this CORS issue comes down to browser policy. Right now I'm testing from localhost over https. Once the front end code is deployed to a proper domain, will the error persist? Is there any alternative way to get around this?
Thank you!
On all OAuth2 documentations i looked, including the Oauth2 spec, the Oauth2 Authorization Code flow ends in the point where the server side holds both the refresh and access tokens.
As a server-side of a web app, what I wish is to not finish the flow here, but response my web user agent with the access\refresh tokens
This in order to have my user agent later make calls to my app's server-side APIs using the access token for auth (the app's server-side will verify the token against the authorization server).
The implicit flow might be the flow i should have been using here (right?), but the authorization server in my company supports only the authorization code flow (and not the implicit flow) for now.
I thought of adding a redirect url as a query param inside of the redirect url of the authorization API.
This way, when the authorization flow will ends, and my app's server side will get the tokens, it will redirect back to the User agent's url, providing the access\refresh tokens as hash fragments
Is it safe for the server-side to redirect to user agent with the tokens this way?
Is there any better practice for redirect back to the user agent?
I am writing a REST API to be consumed by our internal applications. I need to login and logout users of the identity server using code grant via http requests
presentation
I need to know how to call the following endpoints:
/authorize (invoked from server-side)
/accesstoken (invoked from server-side)
/login
/logout
CASE:
Our company has many applications. I want one point of authentication which will happen in their company-x account like how you only need to login to atlassian account to access jira and confluence cloud. The REST API I'm working is for our front-end developers (as of now).
presentation
I cannot simply let the user login to WSO2 IS since they only need a module where they can manage their company-x profile and other basic stuffs. By this I think I have 2 options:
Customize WSO2 Identity Server UI and permissions. But the problem is, I still need an endpoint to get that id_token. I am also not sure if this is the right approach.
Know how to call /authorize, /accesstoken, /login and /logout endpoint and write my own minimal required UI and provide an endpoint that will respond the id_token
How about having a basic login page on front-end and use request path authenticator to get the authorization code/id_token.
Basically what this means is instead of redirecting the user to IS login page you can extract the username and password from the basic login page you created and send the authorization grant request along with the credentials.
so your authorization code request will be:
https://localhost:9443/oauth2/authorize?response_type=code&client_id=JqB4NGZLMC6L3n4jz094FMls2Joa&redirect_uri=https://localhost/callback&scope=openid§oken=<sec_token>
sec_token = base64encode(username:password)
You need to add basic-auth request path authenticator in your Service Provider configurations. This request should return you an authorization code. If you want an id_token simply use the implicit flow with request path authentication.
If you use code grant type, there will be a browser redirection from /authorize to /login. I don't think you can handle that by a REST call. (You might be able to handle that by calling url in location header of each 302 response. But I don't think it's a nice way to do this.) If you want to develop a REST API, I think password grant type will be more suitable.
In the Google developer console, when you create new app credentials for use in OAuth 2.0, and you specify a web app, it requests that you register callback URI and JavaScript origins.
I don't have a precise understanding of the need to register these.
For the callback URI, presumably this prevents a 3rd party who presents a malicious page to a user from getting the authorization code. However, the client id and secret are still hidden in the app server, so isn't the malicious application unable to do anything anyway?
Furthermore, if the callback URI is already registered, what does registering the JS origins separately accomplish. Unlike the callback URI registration, this is not mentioned by the OAuth 2.0 spec, it's something Google chose to implement.
Thank you for your help!
When you request a token, that token will be passed to the callback URL. By only permitting callback URLs that you have configured in the API console, you are preventing malicious users from spoofing the request and having the token sent to a third party. I suspect the aspect of OAuth that you've missed is that the callback is sent via a browser redirect, so is easy to fake.
Callback URLs are part of the OAuth server flow.
JS Origins come into play when you are using the client (Javascript) OAuth flow. They ensure that any OAuth request has come from a page that originated on your site.
The server flow is ...
OK I think I understand a bit more from reading the spec. https://www.rfc-editor.org/rfc/rfc6749#section-10.6
It is to prevent an attack by a user of the same client An attacker can create an account at the same client and initiate auth flow, but he replaces the redirect URI with his own URI.
He then tricks a victim into following the link to authorize the same legit client they are using. However, the auth code is now sent to the attacker URI.
The attacker then completes the flow by providing the auth code back to the client, which the client uses to complete the flow obtaining the token. However, this token may be associated by the client with the attacker, allowing him to impersonate the victim.