How to design an extensible login function

This article mainly shares how to design an extensible login function.

1. Multiple login methods (you need to have a unique value to bind various login methods. At present, mobile phone numbers are mostly used in the industry)

1. Username + password login

The most original login method, this login method is separate from the registration function, and the industry has gradually given up on this method

2. Mobile phone number + verification code to log in

The login method used by most of the industry, this login method and the registration function are integrated, but this method has problems with the experience of obtaining SMS verification codes

3. One-click login with local number

Based on the optimization of method 2, the login experience can be maximized

4. Third-party authorized login (such as WeChat, Weibo, QQ, etc.)

With the optimization of the login method, the login experience can be the same as that of method 3. The authorization here refers to the code obtained when the third-party platforms such as WeChat, Weibo, and QQ are authorized to log in. According to this code, the user information of the third-party platform can be obtained (such as openid, unionid)

5. Mobile phone number + verification code login + binding third-party authorization

As a supplement to method 4, it is generally carried out when method 4 is completed. Usually, after authorization and login, it is not known whether the user already has an account, and the mobile phone number needs to be introduced for unique value verification.

2. Design an authentication service in the microservice, and the above login methods are unified in the authentication service

1. The C-side API can be roughly divided into two types, one is accessible after user login, and the other is accessible without login

2. If the request does not have a token, it must be logged in; if it has a token, it may not necessarily be logged in, and the token may be invalid

3. If you have a token, do unified processing at the gateway, parse the token to get the user ID inside (set in when the token is generated) and set it to the header to be passed inside the microservice. If the token expires, do not set it to the header

4. The microservice at the BFF layer judges whether the user is logged in based on whether the header can get the user ID. If it is an API that needs to be logged in to access and has no user ID, it will respond with a fixed error code and agree with the front-end colleagues to respond to the error. Code to guide login

5. The login request is forwarded to the authentication service, the registration/login is integrated, and the response token is sent to the front end, which stores the token locally, and all subsequent requests carry the token

3. Core code

1. Login interface code

2. Parse the token to get the user ID and set it to the header

3. According to whether the header has a user ID or not, it needs to log in to the API

4. Storage table structure

CREATE TABLE `bu_user_info` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `nickname` varchar(32) DEFAULT NULL COMMENT '昵称',
  `avator` varchar(32) DEFAULT NULL COMMENT '头像',
  `remark` varchar(255) DEFAULT NULL COMMENT '备注',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户信息表';
CREATE TABLE `bu_user_oauth` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `user_id` int(11) NOT NULL COMMENT 'bu_user_info.id',
  `identity_type` varchar(32) NOT NULL COMMENT '账号类型(mobile:手机号,wx-unionid:微信unionid,wx-openid-miniapp:微信小程序openid,wx-openid-mp:微信公众号openid,email:邮箱,username:用户名,sina:新浪微博,qq:QQ)',
  `identifier` varchar(32) NOT NULL COMMENT '手机号、邮箱、用户名或第三方应用的唯一标识',
  `certificate` varchar(255) DEFAULT NULL COMMENT '凭证(站内的保存密码,站外的不保存或保存token)',
  `remark` varchar(255) DEFAULT NULL COMMENT '备注',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE KEY `uniq_ui_it` (`user_id`,`identity_type`),
  UNIQUE KEY `uniq_identifier_it` (`identifier`,`identity_type`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户认证表';

How about it? If you find it useful, don't hesitate to collect it! ! !

Attachment: the code directory involved

github:GitHub - 897665787/springcloud-template

gitee: springcloud-template: A microservice framework based on springcloud netflix, which records some of the best applications for microservice development. Welcome to learn and guide.

springcloud-template
└── template-auth
     └── authentication
          └── LoginService -- 登录抽象定义
               └── AppWeixinService -- APP微信授权登录
               └── LocalMobileService -- 本机号码一键登录
               └── MobileCodeBindService -- 手机号+验证码登录并绑定授权码
               └── MobileCodeService -- 手机号+验证码登录
               └── UsernamePasswordService -- 用户名+密码登录
               └── WeixinMiniappService -- 微信小程序登录
               └── WeixinMpService -- 微信公众号登录
          └── LoginType -- 多种登录方式定义
     └── controller
          └── AccountController -- 登录API
     └── token
          └── TokenService -- token抽象定义
└── template-framework-edge
     └── interceptor
          └── AccessControlConfigurer
          └── AccessControlInterceptor -- 根据header有无用户ID拦截需登录API
└── template-zuul或template-gateway
     └── filter
          └── TokenFilter -- 解析token获取用户ID并将设置到header

Guess you like

Origin blog.csdn.net/w13528476101/article/details/126907433