Oauth2 in Vue.js - vue.js

I've built a single page app in vue.js (v2) and am now trying to handle authentication.
The Oauth2 authentication workflow is the following :
get authorization code url from identity provider
get token based on client_id + client_secret + authorization code + scope from identity provider
I honestly don't know where to start...
The identity provider docs states that "For succefull authorization process, be aware to specify the same redirect_uri for the requests GET /oauth/get_authorization_code_url and POST /oauth/token" which is unclear for me because the response for those two requests are obviously different. So not sure how to handle that.
Do you have any documentation / packages that i could use for this use case ?
Thanks for your help.

Related

OAuth 2.0 token introspection questions

I'm trying to understand token introspection as I need to implement token introspection for OAuth 2.0. But authentication is so hard to understand... :-( So I've got a couple of questions:
(1) As far as I understand, a post-request (with the access token) is sent to the IP. This then returns whether the access token is valid or not, as well as further information such as the user name.
This looks like the official spec to me: https://www.rfc-editor.org/rfc/rfc7662 it says a post request is needed to validate the access token. Did I understand that correctly
(2) This looks like the corresponding dependency, is it? using using IdentityModel.AspNetCore.OAuth2Introspection
Whats the difference between Microsoft.AspNetCore.Authentication.JwtBearer?
(3) According to the spec only the access token is requied (https://www.rfc-editor.org/rfc/rfc7662#section-2.1)
This example does not pass it but the clientid and the clientsecret:
https://github.com/IdentityModel/IdentityModel.AspNetCore.OAuth2Introspection
services.AddAuthentication(OAuth2IntrospectionDefaults.AuthenticationScheme)
.AddOAuth2Introspection(options =>
{
options.Authority = "https://base_address_of_token_service";
options.ClientId = "client_id_for_introspection_endpoint";
options.ClientSecret = "client_secret_for_introspection_endpoint";
});
Why not?
(4) If I set the config right, .Net Core will do the post-request (for every incoming request to my api) for me automatically, right? (I also added the [Authorize]-Attribute)
(5) How can I get the user context?
(6) I implemented a small example but get a 500. I do not see any error output. How can I log the errors?
The following are some of my understanding and opinions:
(1) The token introspection endpoint needs to be able to return information about a token, so you will most likely build it in the same place that the token endpoint lives. The request will be a POST request containing just a parameter named "token".
(2) JWTs are typically validated locally on the resource server.
It's a technical detail that IdentityServer can also validate JWTs at the introspection endpoint. That could be used e.g. when the resource server does not have an appropriate JWT library (and you don't want to store reference tokens on the IS side).
(3) In my opinion, this appears to be a configuration requesting an access token. Access tokens are the thing that applications use to make API requests on behalf of a user. The access token represents the authorization of a specific application to access specific parts of a user’s data. The Client Credentials grant is used when applications request an access token to access their own resources, not on behalf of a user. Please check this link: Access Tokens.
(4) If you add the [Authorize] attribute to the method that requires authorization, if the configuration is correct, the .Net Core App will automatically request authorization from the authorization server with your information.
(5) Do you want to access end user context on resource server? Maybe this link can help you.
(6) For logging error messages, please refer to this link: How do I log authorization attempts in .net core.
Hope this can help you.

How does Auth0 API validate an access token?

Everything is working except for what happens between Step 6 and Step 7. When my backend receives the access token from the browser, how does the backend validate that access token? I assume, that the backend doesn’t make a call to Auth0 to validate that token because there is no arrow back to Auth0 after Step 6. So, how does the backend know that the token it received is valid?
I have an SPA and a API which I would like to follow this flow:
https://auth0.com/docs/flows/concepts/implicit
And also this document how to API validates the Access Token?
The following is the standard way to validate the access token.
Check access token is well-formed.
Validates the signature which is used to sing the access token. In that case, backend application perform an API call to JWKS endpoint to retrieve the public key
https://auth0.com/docs/jwks
Validates the standard claims
Validates the permissions(scopes)
More Details can be found here:
https://auth0.com/docs/api-auth/tutorials/verify-access-token
https://auth0.com/blog/navigating-rs256-and-jwks/
If you are using any auth0 SDK, it performs the validation as described.
Additionally, ID token is also required to be validated in the frontend client. https://auth0.com/docs/tokens/guides/id-token/validate-id-token
Between step 6 and 7 of the doc you referenced it dives into your backend validating this Access token. Depending on your backend there are a large number of quickstarts to help you gain traction moving forward. I will link the docs below along with Auth0 video training on identity to help solidify a great foundation when tackling the Authentication subject. Please let me know if this helps you!
https://auth0.com/docs/quickstart/backend
https://auth0.com/docs/videos/learn-identity/

Authorization Code Flow and PKCE example using OpenIddict

I stumbled upon OpenIddict and after going through a few example server code, I could not find what I was looking for. I was hoping to see an example of OpenIddict using auth code flow with PKCE, since that seems to be the recommended approach toward security now, but could not find one using both explicitly. My app is a ASP.NET Core WebAPI based app, with a React client. Any help or guidance would be appreciated.
PKCE in OpenIddict works like in any other OIDC server: you just have to send a code_challenge (and optionally a code_challenge_method) when building your authorization request.
If you do that, OpenIddict will store it in the authorization code ticket and will compare it to the code_verifier you send as part of the token request. If you don't send a code verifier, the token request will be automatically rejected.
In 3.0, we'll introduce an option allowing to reject authorization requests that don't use PKCE so that you can force your clients to use PKCE.

Best practice to receive JWT from third party provider?

I am playing with JWT and expressJS to learn something new, and come up with the idea to make my little JWT provider to use for all my future personal projects.
The idea is quite simple, my provider will register with facebook and twitter API, and will use passport to authenticate with them. I will also store users credentials so I don't need to worry about that in my other projects (these project will hold their info about users but various data from socials/passwords etc.. will be in the provider).
I coded this little workflow:
I register the app in my provider with a callback url
Put a button (e.g. 'Login with Twitter') on my project, that links directly to my provider
when I accept the Twitter conditions, twitter callback calls my provider that pick the right user and redirect to my project.
I am stuck on this last point, I would love to pass to my project the JWT token to use for its next requests, but how do I pass to it?
Cannot set cookie because domains are different obviously, I am missing something? Did I follow the wrong way?
The authentication flow you describe is similar to OAuth2. I suggest to read the RFC 6749. It explain the technical details to implement it. You can also refer to OpenID Connect. It is an extension of OAuth2 using JWT
Basically you need to create an access token after a successful login and return a redirection to the callback url. The adapted flow to your context could be the following
App redirects user to central login form
The server prompts user for the credentials :It returns an HTML form with the supported authentication methods, that can include a connection with a third party authentication provider
After a successful authentication, the server creates an access token. It can be a JWT
The server returns a redirection to the provided callback url. It includes an authentication code
The app request the authentication server using the previous code and get an access token
The token can be used by app to access to a protected resource
In Oauth2, the access token it is just a random string, but you can use JWT perfectly.

Adding OAuth 2.0 authentication to a RESTful API

I have an API that requires authentication via OAuth 2.0. I originally anticipated using HWIOAuthBundle, however from investigation this is more to do with hooking up 3rd parties into Symfony's security/auth mechanism and does not provide the required mechanism for validating OAuth 2.0 Authorization headers.
I then found some information about FOSOAuthServerBundle which enables an application to become it's own OAuth 2.0 provider as well as providing the required security mechanisms to validate Authorization headers.
However the problem is that I would like integrate the OAuth 2.0 provider (authorisation server) in an external application (which contains the user base) and not include it within the API. Which will provide some mechanism for performing the token verification against this external app via (another) RESTful API.
Points:
RESTful API requires OAuth 2.0 authentication.
OAuth 2.0 authorisation server to be situated in a separate application.
I feel I should use Implicit grant and call the authorization server on each request to validate that the token is correct.
Is my thinking correct?
As far as I undesratnd your requirement, you require to authenticate your APIs via external OAuth Authorization Server:
Client needs to provide the access token retrieved in the above steps
along with the request to access the protected resource. Access token
will be sent as an authorization parameter in the request header.
Server will authenticate the request based on the token.
If token is valid then client will get an access to protected resource otherwise access is denied.
here is an example which might help you to achieve your requirement. Check this document .
Or simply, you can do with Jersey and Oauth
Also, you can check Apache Oltu and figure out the way to achieve your requirement.
A lot of the big companies like Google, Facebook etc have a separate authorization server from the API server. Check out Google's OAuth authorization flow below
You can also check Google's OAuth Documentation for the details.
So all you would need to do is implement a OAuth Provider so that you can authorize against that provider. There's a list of libraries available on the OAuth website: http://oauth.net/code. You can specifically look here; there is an example for running an OAuth Service Provider in Java.
oAuth can most definitely be a server other than your application server. Below is a picture of what the authentication sequence would look like:
-- Obviously, if the forum can't decode or validate the token, the forum would return a 401 status code instead of a 200 status code.
As long as your oAuth server & the Forum share the same public key, you're more than okay with splitting your oAuth Server & your application.
In fact, take a look at jwt.io. Paste the token you get from the oAuth server into there. It should be able to decode the token right away. Then, you can put your public key into the 'secret' text box to verify the token is verified.
Your application (Forum, in this example) should be able to do the same:
1) Grab the token from the Authorization header of the request
2) Decode the token
3) Check the expire date
4) Verify the token using the oAuth's public key
5) Return successful status code or a failure status code