Failing at API dev

[Solarion]

Hi guys. I have a question on the MVC side regarding authentication. If you could please offer some clarity.

It is in regard to sending the token back to the API on a request for resources.

Now I have been doing it this way up till now; storing the token in a session object: http://binaryintellect.net/articles/db752e63-8e07-4760-b7f2-a882e67636ce.aspx

Then whenever I send a request to the API I access and send the token as such:

ServiceClient

What has led me to start questioning my own reality was when I was doing some digging around about accessing tokens and found something related to this; requesting the jwt via a cookie object. After several attempts to do it this way, all I kept getting back was the AntiForgery token when doing this way, NOT the actual token from the API.

Middleware

services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
.AddCookie("Cookies", options =>
{
    options.LoginPath = "/Account/Login";
    options.LogoutPath = "/Account/Logout";
    options.AccessDeniedPath = "/Account/AccessDenied";
    options.ReturnUrlParameter = "ReturnUrl";
    options.Cookie.Name = "bearer_token";
});

ServiceClient

httpContextAccessor.HttpContext.Request.Cookies["bearer_token"];

As I mentioned this is only giving me back the AntiForgery token. Is my previous way of storing in sessions correct or am I doing something critically wrong? Please advise!

 

[DA-LION-619]

Is my previous way of storing in sessions correct or am I doing something critically wrong? Please advise!

So is this what you were kinda planning?

You’re asking the wrong questions ;P
I refer to the above diagram, you’ve extracted your authentication/authorisation infrastructure into a separate web service but then you’ve gone and coupled it back in with your MVC project.
(Which service is really responsible for Identity?)

That was OT. Yes you’re using sessions correctly.
Before trying to use cookies, did you look up how sessions work?

 

[Solarion]

You’re asking the wrong questions ;P
I refer to the above diagram, you’ve extracted your authentication/authorisation infrastructure into a separate web service but then you’ve gone and coupled it back in with your MVC project.
(Which service is really responsible for Identity?)

That was OT. Yes you’re using sessions correctly.
Before trying to use cookies, did you look up how sessions work?

Thank-you DA. I gotta tell you I wasn't totally happy with storing sensitive stuff in a cookie. I am come from an old school Asp (yes not even .net yet) background and we used to use a lot of sessions to store login details because the session was destroyed upon closing of the site or logging out (either forcibly or automatically depending)

In 2012 I veered away from web dev sphere into desktop development (something I still regret) so have some catching up to do. If session still work the way I think they do then they are a great choice to prevent a hacker from sniffing around in persisted site data. Could be totally wrong though ofc!

services.AddSession(options =>
{
    options.IdleTimeout = TimeSpan.FromSeconds(10);
    options.Cookie.HttpOnly = true;
    options.Cookie.IsEssential = true;
});

Edit: For anyone interested

Session in ASP.NET Core

Discover approaches to preserve session between requests.

docs.microsoft.com

 

[_kabal_]

You still use a cookie with a session. That is how the server knows what your session is.
That is how you can be logged in on one tab, and open the site on another tab and you are still logged in.

sessions are not great for distributed or load balanced systems (without sticky sessions), as you then need to externalise your session store into something like redis.

this is where portable systems like jwt come into play. The jwt, instead of the session ID, is stored in the cookie.

You also might be using a client that isn’t a browser, like a native sdk http client

 

[Solarion]

You still use a cookie with a session. That is how the server knows what your session is.
That is how you can be logged in on one tab, and open the site on another tab and you are still logged in.

sessions are not great for distributed or load balanced systems (without sticky sessions), as you then need to externalise your session store into something like redis.

this is where portable systems like jwt come into play. The jwt, instead of the session ID, is stored in the cookie.

You also might be using a client that isn’t a browser, like a native sdk http client

I just logged in on one tab, opened another blank one and pasted one of the url's from the mvc, it went there fine.

I then repeated, opened a blank tab, closed the actual site, left it for about 10 seconds, then pasted the same url to get users, and it redirected to Login. So all seems to be ok there!

That's the thing, the client may even be a desktop app. So I have to consider all of those things all the time whatever I do. I've tried to make the client as independent of actual MVC libraries and what not as possible with the thought in mind that: "Could someone do this same task or thing in a desktop or angular app?"

 

[Solarion]

@DA-LION-619 That graphic you posted, is deal yes. Also, to get the token from say an authentication server rather than fussing about with it in the client. I've yet to get there!!

I can't imagine say an external company that is tasked with designing a banking app (like Capitec) would be given the secret.