Where to save user authentication token: cookies vs local storage

Here's a very good comparison:
https://stackoverflow.com/a/35347022/171950

The important part in the link above is that local storage approach is CSRF protected, but exposed to XSS.

see also:
https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-2.2

OAuth 2.0 and OpenID Connect (OIDC) flows

4 flows for OAuth 2.0:

• Code flow:
• auth server sends auth authorization code then client uses the code to get the access token
• fit for web apps (where the work is done over a front-channel) 
• has refresh token
• Implicit flow:
• auth server sending the access token directly
• fit where the client is a native app (mobile, desktop, etc)
• doesn't have a refresh token, but some people work around it.
• Resource owner credential flow:
• the client app gets a token by sending the username/password of the resource owner to the auth server
• fit for enterprise-trusted apps (like on-prem services, like on-prem JIRA server when user enter his LDAP credentials), or regular client apps that connect to the corresponding backend service. (like mobile front-end connects to the backend, so the resource owner enters his own username/password into the client app to get an access token and a refresh token)
• has refresh token.
• Client credential:
• service-to-service flow, no human interaction.

OpenID Connect (OIDC) builds on top of OAuth 2.0 by adding extra staff like id_token and userInfo endpoint and it reuses the first two flows (code & implicit for server and native clients respectively)

About web security (1)

We usually implement web security with Roles and Permissions.

a Database Table for users and one for Roles which users belongs and one for Permission for the roles which the users a role should have.


[Users Table]    <- Many-to-one -> [Roles Table] <-  One-to-many -> [Permissions Table]

The above model is the basic, but we can add extra relation between the Users and the Permissions to allow direct permission on the table regarding the role in which the user belongs.


The Authentication does from the Users table.. the user is there and not disabled.

The Authorization is all about answering the question of "Is the user has access to this restricted object?"

How Authorization done?

In Web - where the restricted object is all about URL resources - the autorization is done as follows:

• Every resource (a pattern for resources) in the system (should) have a list of permissions associated (usually only one) with it.
  Usually defined in the Permissions table as URL -> PERMISSION mapping. (or in XML as of spring-security)
  ex: '/editMyProfile.html' url mapped to CAN_EDIT_PROFILE permission.
  
• When the user successfully login, a list of all permission is attached to him (either role permissions or user permission as discussed before)
  
• Then when the user requests some URL, The system checks if the user has some attached permission that in the list of permissions that is associated with the url. If yes then the system allows the user to access the page, otherwise HTTP 403 is returned to the user.

How to draw the menu:

First you have your structure of menu (tree menu, list menu or whatever).

Initially, get all urls from Permissions table of the database and draw this permissions as following:

for (Permission p: permissions){

     if (userHavePermission(p.getPermissionName()){

           out.println(p.getUrl());

     }

}

the above is very simple code example.

Also you can consider nesting the menus by having a self-referential relationship in the Permissions table.

SMAuth, Simple Mobile Authentication

SMAuth is a simple mobile (and desktop) apps authentication schema. SMAuth is most suitable to run over HTTPS.

The whole idea here is to keep the client out of persisting the username/password and instead persist a token that will expire.

SMAuth is more suitable for Mobile and Desktop applications where the Resource owner (who know the username/password) is the client himself.

Learn More: http://code.google.com/p/smauth/

code: https://smauth.googlecode.com/svn/trunk/