We have Resource API protected IdentityServer, On this We want to Add a Middleware, that will check the incoming request and will do some processing on it.
But we want this processing logic to get executed only for Authorized requests.
Please do let me know Where we can add this middleware and how I can confirm the request is authenticated.
We want the middleware to be added before MVC
Add the middleware after the UseAuthentication and before UseMvc. You will be able to inspect the context in your new middleware to see if it is authenticated or not.
Related
I have a project where I use Next.js on the front-end and Nest.js on the back-end.
I want to use a JWT authentification method via email and password.
My question is:
What is the best way to implement an authentification for Next.js with custom Back-end.
I'm sending API requests through redux-saga to get some data from back-end.
For me the Set-Cookies from the back-end not work. It's not applying on the client browser.
For now my possible solution is to create a custom axios instance and somehow do the Auth check there.
But I'm sure there should be a better solution, thanks for help!
For now my possible solution is to create a custom axios instance and somehow do the Auth check there.
Yes. This is the correct way of going about it. Give the token to whatever you use for queries and let it handle it for you.
You have a number of different ways of achieving this.
Provide it via a side-effect
Whenever a login event happens, run a side-effect to configure your axios instance to always send the newly acquired token with each request
Set the token in your cookies or localstorage and let axios retrieve it for each request
Set the token in a context and only make requests through that context with a hook
I've a Gatsby (React) page with a contact-form which sends the params to an API endpoint.
The form is on the browsers client side.
That Api Endpoint sends to an Email service provider, so far so good.
BUT how can I prevent people from sending emails directly to that endpoint /api/contact-form, in my contact-form I have a ReCaptcha to do that, but the API endpoint is not "secured".
First I thought I can do that with a "host"-check... but the page is on the client side...
Is it the right approach to create a token, when the page is delivered to the client, and check it then against on the API endpoint?
I assume you're talking about CSRF token. It is definitely one way to prevent CSRF attacks. The other option could be setting cors to allow only specific origins to access your API endpoints.
I got a single page app written with React and ReactRouter and the frontend seems to be easy going.
But I have no idea how to design a backend which is only accessable by admins. On the server-side I use a NodeJS / Express RESTful API which uses JWT (JsonWebToken) for authentication.
Do you have any ideas?
You can use Express Middleware to check and validate JWT. If the JWT is valid then proceed with the API otherwise redirect to login. There are lots of articles available on ExpressJs site about middleware.
One great option is express-jwt
You import it, make a middleware, and place it before any protected route. If the token is valid, req.user will be set with the JSON object decoded to be used by later middleware for authorization and access control.
const jwt = require("express-jwt");
const auth = jwt({
secret: jwt_secret
});
router.get("/secret/:uid", auth, profileCtrl.secret);
I am using IdentityServer4. I have configured Google authentication middleware as seen here. However, the redirect uri registered with Google is <domain>/signin-google. Additionally, I know that the ExternalLoginCallback endpoint gets called after I have authenticated with Google and after the redirect uri that is registered with Google has been called (/signin-google).
My question is what happens between /signin-google and the call to /ExternalLoginCallback? What method(s) in the Google middleware are triggered once the browser is redirected to /signin-google but before the application/middleware eventually makes it to /ExternalLoginCallback?
If you look at the ASP.NET Core Security Github repo you can find the implementation of the Google middleware. Essentially, if you trace through the code you will see the GoogleHandler inherits from OAuthHandler<T> which inherits from RemoteAuthenticationHandler<T>. In RemoteAuthenticationHandler<T> you will see a method called ShouldHandleRequestAsync (here). This method checks the current URL versus the URL that is on the CallbackPath property on the Options object. This is how the authentication middleware is triggered after the redirect back from the authentication provider - it's handled by the middleware - NOT a controller. Once the middleware is triggered it resumes the authentication process.
All external authentication provider middleware works this way. Once the middleware is triggered a method called called HandleRemoteAuthentication in OAuthHandler is triggered. See here. This triggers the second leg of the OAuth 2.0 authorization code flow process where the one time use code obtained in the first leg of the process is exchanged for an access token. That process happens before the ExternalLoginCallback is triggered. Specifically, once the code has been exchanged for an access token and some user information is obtained from Google a ClaimsPrincipal is created and a temporary cookie is issued. By default the cookie is named idsrv.external. Then, as you can see in the IdentityServer4 Quickstart projects, the ExternalLoginCallback endpoint is triggered, the idsrv.external cookie is deleted and a new authentication cookie is issued for the ClaimsPrincipal.
The Google middleware overrides functionality from the base classes that is specific to Google, but essentially all of the OAuth 2.0/OpenID Connect middleware works this way.
I have a Backbone/RequireJS application built on top of .NET MVC4. I am using Forms Authentication to authenticate the user against our back end data store, and this is working great.
Our services layer is a .NET Web Api Project (RESTful API), and is using a tokenized approach to auth (initial request includes basic auth header. If auth is successful, response payload includes authentication token. Subsequent requests pass the token).
What I'm not sure about is how to now authenticate against our services layer. I'm sure I'll have to pass the auth header, but not sure how to generate the token, as I won't have username/password in my JS.
Should I bypass Forms auth altogether here, and simply make an ajax request over SSL? I can POST to the /Account/Login action just as well, and use the Membership Provider to validate credentials. If successful, I can add the Auth header for initial request & use auth token for subsequent requests.
Example of adding auth header / custom token here:
$.ajaxSetup({
'beforeSend': function (xhr) {
if($.cookie("AuthToken")) {
xhr.setRequestHeader("CustomTokenHeader", $.cookie("AuthToken"));
} else {
var token = methodToBase64EncodeUsernamePassword(username, password);
xhr.setRequestHeader("Authentication", "Basic " + token);
}
}
});
Take a look at this solution, which is based off a screencast I cannot seem to find again. If I can find it, I will update the answer. You should be able to follow the solutions easily though. The one you are looking for is PerRouteMHOwnershipSample. I believe the best practice is to 'bypass Forms auth altogether here, and simply make an ajax request over SSL'. Any api route you want to secure, will be filtered and a token will then need to be passed from your app and decoded on the server. I would personally not look at using Forms Authentication to secure your api.