open source - https://github.com/KeroVieux/fingerprint-web-auth-proposal

why I show you this

There are many guys require to settle cross-domain token, but all most all reply is it not gonna happen, please change your mind.
Trust me, it easy to make it happen, just follow my step, this proposal will show you something brand new.

confirm that what you need to address

  1. prohibit users to share the link to someone else;
  2. always can get the user token or the userId, whatever the user link to which domain;

How to do

  1. use fingerprint2 to identify the user's device
  2. in order to increase the probability of detection that device as unique, get the user's IP is required.
  3. set up a database to store the login record
  4. when a user login one of your app, you insert a record to the database, like { authId, IP, fingerprint,jwtToken }
  5. when a user needs to check the auth status, you can search the database, match this user's { authId, IP, fingerprint }

disadvantage

  1. a user shared a link to a man who has the same fingerprint info, that will be leaked information ( I assert just a few people have the same fingerprint info)
  2. users can share the link / authId / fingerprint info with other people(I just can say someone can share their account and password with other people, how can you stop it)

3 api

login

  1. after the oauth action, you have got the userId
  2. post the data { userId, fingerprint } to the login api, that will return a authId
  3. store the authId in localstorage

check

  1. post the data { authId, fingerprint } to the check api, that will return a userId and the jwtToken
  2. if it is not a legal user, the api will return false

logout

  1. remove the authId in localstorage
  2. post the data { authId } to the logout api, that will return true.

enter an app in a different domain

  1. the href should be xxx.com?authId=:authId
  2. store the authId in localstorage
  3. post the data { authId, fingerprint } to the check api, that will return a userId

what now

  1. you can see, when a user stays in your app have the userId, it can assert it as a legal user.
  2. post the userId to your access center server to check the user's auth
  3. post the userId to your user center server to get user profile
  4. use the jwtToken to require api what you need.

思路详述

当前流行方案JWT

流程

  1. 账号密码登录，得到有时限的token
  2. 存入localstorage，请求其他接口在headers.auth中加入token
  3. 服务端验证token，匹配权限后进入自身逻辑

当前需求冲突

  1. 现在的趋势是设备校验身份（参考手机的指纹验证进入app，mac的指纹验证进入系统），密码不再是唯一登录方式，
  2. 用户更倾向于自己的设备不应该有授权时限，要求用户重复登录
  3. 跨域使用token基本上很困难

重新设计fingerprint web auth - FWA

说明

目的

  1. 用户只能自己浏览网页，阻止分享他人，泄露信息
  2. 能够跨域使用授权信息
  3. 取消授权时限，只依赖设备加密

使用方法

  1. 使用fingerprint2，识别唯一设备(不是绝对成功)
  2. 为了让同型号同设置的设备不重复，授权信息表加入ip记录，网络环境改变也需要重新登录
  3. 身份校验需要authId fingerprint ip完全匹配

已知弊端

  1. 用户分享自己的网页给一个拥有一样fingerprint的人，就会泄密(同型号、同批次、同设置、同网络下的你们，关系非同一般，泄密似乎不可怕……)
  2. 恶意分享authId fingerprint给他人进行泄密(jwt还恶意分享账号密码呢……)

我一定要用jwt!

  1. 当然可以，这个不冲突的，用这个设计思路把jwt token存入授权信息表中，跨域也能获得token

第一步 登录

初次登陆或注销后登陆

  1. if !authId, 则需要扫码或点击按钮进行授权认证，得到userId
  2. 在授权信息表储存身份信息, required: userId fingerprint,返回authId
  3. localstorage储存authId

再次使用

  1. if authId
  2. 请求授权信息表，required: authId fingerprint，同时匹配返回userId

检验授权失败

  1. 缺少authId
  2. authId fingerprint ip，不完全匹配

授权信息表设计

  1. userId
  2. fingerprint
  3. ip
  4. createdAt

第二步 跳转其他域名获取授权

  1. 跳转网址，query需要authId, 例如 xxx.com?authId=:authId
  2. localstorage储存authId
  3. 请求授权信息表，required: authId fingerprint，同时匹配返回userId

请求其他接口

  1. 将authId fingerprint加密后加入header.Authorization字段中
  2. 接口解密header请求授权信息表，required: authId fingerprint，同时匹配返回userId
  3. 使用userId查询权限中心，当前用户和当前接口匹配后进入自身逻辑

注销

  1. 清除localstorage的authId
  2. 请求授权信息表，required: authId，软删除该记录
  3. 重新登录