While I was learning how to integrate Facebook Authentication into ASP.NET MVC application I have written a code that uses session state to store the access_token obtained via Facebook JS SDK. As soon as the java-script code has the access token, it is being posted onto a special controller action that stores it in Session dictionary.
I would like to avoid the use of Session but to still have the access token available to retrieve user info. Is it safe to just store it in a non-permanent cookie? Will the effect be the same?
It might interest you that the official PHP SDK stores the access token in a session, or in the signed_request which is stored in a cookie. However, the signed_request is encrypted using the app secret which is a lot more secure than storing the access token unencrypted.
https://github.com/facebook/facebook-php-sdk/tree/master/src
Also, here's a previous discussion on stackoverflow about cookie vs session security:
Do i login using cookies or sessions in a login system?
You may create your own encrypted signed request if you please, however never do that from your client (because it would require storing the secret on your client). For more info see the PHP SDK and/or the link:
https://developers.facebook.com/docs/authentication/signed_request/
Related
I completely don't understand the next-auth documentation.
I understand you can use both JWT and sessions, but how do you tell next-auth which one you're using?
And where does next-auth store its sessions or JWTs? On the server or client-side?
NextAuth.js uses a JWT to save the user's session by default, when a database adapter is not used.
NextAuth.js by default uses JSON Web Tokens for saving the user's
session. However, if you use a database adapter, the database will be
used to persist the user's session. You can force the usage of JWT
when using a database through the configuration options. Since v4 all
our JWT tokens are now encrypted by default with A256GCM.
The JWT is stored in an httpOnly cookie, not accessible on the client-side.
You can use JWT to securely store information you do not mind the
client knowing even without encryption, as the JWT is stored in a
server-readable-only cookie so data in the JWT is not accessible to
third party JavaScript running on your site.
This is documented in NextAuth.js JSON Web Tokens FAQ section.
I have implemented sign-in to Microsoft to my ASP.NET web application. Everything works as intended, but I am struggling to comprehend how the sessions work. I am using OWIN middleware and OpenID connect.
What is the difference between the SSO-Token and the ID-token? Which
one keeps me logged in?
What happens if I try to access claims ( e.g.
userClaims?.FindFirst(System.Security.Claims.ClaimTypes.sid)?.Value)
from an expired ID token?
How does !Request.IsAuthenticated realize that the current user is
Authenticated after the microsoft login? Is this because The Generic
Identity, is now a Claims Identity, that returns true?
If I am logged in, and keep refreshing the site, at what point will
I be forced to Authenticate again? And what controls this time?
I understand what an ID-token is, and that it carries claims, and how I access and use the claims. I am just confused about how the session works after a user has logged in with their Microsoft account.
There is no SSO token. The id token represents proof of authentication and some basic user info is included in it. So your web app can get name, email etc.
Expiry is based on an auth cookie that the MS libraries issue. This is tied to another token, the refresh token, which represents the session time.
The id token has a digital signature that is cryptographically verified. Also your app supplies a client secret to help ensure that tokens can be trusted.
The cookie is given an expiry related to the refresh token. When the cookie expires the user has to login again.
FOR BETTER UNDERSTANDING
I would strongly recommend tracing messages, via a tool such as Fiddler, as in this blog post of mine.
Personally I prefer Single Page Apps, which only use tokens and not cookies. They make OAuth aspects easier to understand and code can be simpler, though there are still plenty of subtleties.
I am building an asp .net mvc project and I want to save the user who is currently logged in , So I read about sessions and cookies and I found that authentication tokens stored in a cookies are a solution for the problem, So I read about them and I need to know If I am understanding this before implementing anything here What I get until now :
After the user logs in, I generate an authentication token (using a GUID generating method)
The generated authentication token is stored in a cookie in the client browser for .....(I don't know for how long would sound acceptable if someone can plot this thing out for me)
The generated authentication token is stored in my database (hashed for further security using SHA256 hashing method) and corresponding to it the account id of the user and its account type (user or admin)
I check the cookie first thing to know where the user will go to the user or the admin or even to log in page
If the user logs out or the cookie expired and then logs in again , I generate a different token and don't use the stored one in the database (Not sure about this one)
I would really appreciate it if someone tells me if I am missing something or I am doing something wrong ?
What kind of front end are you using? If you use razor. You don't need authentication tokens. These tokens are typically used when you communicate with your backend through API calls. You don't store authentication tokens in database. You can store your refresh tokens.
I am trying to implement WEB API 2 (for Single Page App, not as part of Visual Studio project) OAuth2.0 protocol. As per Which OAuth 2.0 flow should I use, using refresh tokens is not an option. However, I am not sure I understand Implicit Grant flow with eventual Silent Authentication.
Does Implicit Flow mean only issuing normal access tokens? In that case, how do we allow user to stay logged in for long time? How should Silent Authentication endpoint look like, what should it receive and return to client? Is using refresh token really an issue - most of people have their usernames / passwords saved in browser?
Does Implicit Flow mean only issuing normal access tokens? Yes.
In that case, how do we allow user to stay logged in for long time? You can set timeout using "expires_in" parameter.
Refer for Complete Detail here: https://oauth2.thephpleague.com/authorization-server/implicit-grant/
How should Silent Authentication endpoint look like, what should it receive and return to client? Upon authentication of the user during login, the server sends & set the authentication key in the session/browser. So, during every page call, only authentication key is send to server. You shall find many examples of implementation online.
Is using refresh token really an issue - most of people have their usernames / passwords saved in browser? No, it's not an issue. If token expires, you can easily reissue token after authentication. Password & username is not saved in the browser. Only authentication key is stored.
Like the Facebook application, you only enter your credentials when you open the application for the first time. After that, you're automatically signed in every time you open the app. How does one accomplish this?
There's a commom line in all auto-login implementations
Upon an initial login, a token is received and stored on the client side
Upon subsequent visits, if token is available on the client side, the server resolves the identity and logs in automatically
Now concrete implementation variations can be numerous. The token can be a session ID (encripted or not), OAuth token, custom token, username and password should be avoided. Storing token can be on within a browser cookie, browser local storage, can have a server counter-part. Security is the major concern. Generally about the topic you can read more here https://softwareengineering.stackexchange.com/questions/200511/how-to-securely-implement-auto-login
You have an interesting explanation of how does Stackoverflow do it https://meta.stackexchange.com/questions/64260/how-does-sos-new-auto-login-feature-work.