단일 포인트 로그 공통 아키텍처를 달성하기 위해
디렉토리
- 1. 단일 로그온 무엇입니까
- 2. 사용자 로그인
- 2.1 인증
- 2.2 라이센스
- 첫째 자 로그인을 달성하기 위해 2.3 아키텍처
- 2.4 아키텍처는 타사 로그인을 할 수 있습니다
- 자사 및 타사 로그인 로그인 인증 2.5 사이의 차이
- 요약 2.6 로그인 아키텍처
- 3. 액세스 제어
- 3.1 분산 인증 구조
- 3.2 중앙 집중식 인증 아키텍처
- 3.3 장점과 분산 및 중앙 집중식 인증의 단점
- 3.4 액세스 제어 세분성
- 3.4.1 HTTP 메소드 레벨
- 3.4.2 API 인터페이스 수준
- 3.4.3 API 구현 수준
- 4. 요약
- 5. 참조
인터넷 응용 프로그램 개발, 사용자 로그인 및 애플리케이션 액세스 제어 서비스는 사용자가 로그온 및 액세스 제어가 필요한 인터넷 응용 프로그램 개발 그래서 직접 응용 프로그램의 안전한 작동에 영향을 미칠뿐만 아니라, 사용자의 개인 정보에 영향을 미칠 중요한 부분입니다 기능적 구성 요소는 인증, 권한, 인증 및 액세스 제어 기능을 네 개의 링크에 관한 것이다. 이 논문 빗 싱글 사인온 (싱글 사인온) 인터넷 응용 프로그램 개발 기술 아키텍처 구현, 사용자 로그인의 단일 지점은 통합 사용자 로그인으로 알려져있다.
- 주 1 :이 문서는 주로 인터넷 응용 프로그램의 개발에 대해 설명이 개 기술의 웹 및 모바일 애플리케이션 개발을 의미한다.
- 주 2 :이 문서의 인증, 허가, 인증 및 액세스 제어에서 설명 된 개념의 정의 이 문서 . 이 문서를 읽기 전에 따라서, 이전의 기사를 읽을 것을 권장합니다.
1. 단일 로그온 무엇입니까
SSO 단일 로그온 사용자 로그인, 해당 구성 요소, 사용자 친화적 인 사용을 제공하는 기술 아키텍처, 통합 인증, 권한 부여, 인증 및 액세스 제어를 제공하는 솔루션보다 단지이 하나의 기능을 달성하고 개발 및 빠른 액세스의 응용 프로그램입니다. 따라서, 단일 사인 온은 간단한 로그인 모듈이 아니다.
싱글 사인온 (SSO)은, 문자 그대로, 그것은 사용자가 같은 계정이 다른 응용 프로그램 서비스에 액세스 할 수 있습니다 사용할 수 있도록하고, 사용자는 한 번에 로그인 할 수 있습니다 (입력 사용자 이름과 암호 번) 여러 권한을 얻을 수 있습니다. 할 수있는 싱글 사인온 크게 사용자의 로그인 작업을 용이하게합니다. 이보기 단일 로그온 사용자의 관점에서입니다.
하나의 또 다른 중요한 수요 기호-에 고려 될 필요가 응용 프로그램이 도킹을 사용하기 쉬운 응용 프로그램이 단순히 쉽고 빠르게 단일 로그온 기능에 액세스 할 수 있도록 단일 로그온 아키텍처는 동안, 클라이언트 구성 요소 및 구성 적절한를 제공해야합니다 권한은 보안 제어를 달성했다.
따라서, 사용자 로그인 및 액세스 제어를 포함하는 보안 아키텍처로 단일 로그온 기술은 두 가지 기능, 후자와 관련된 인증 및 액세스 제어 분야, 전자를 포함하는 인증 및 권한 부여 측면을 필요로한다.
2. 사용자 로그인
사용자 로그인 과정은 일반적으로,이 두 부분은 종종 사용자를 식별이 함께 발생뿐만 아니라인가 된 사용자를 완료하기 위해 사용자 인증 및 권한 부여의 두 가지 측면을 포함한다 .
공급자 로그인 기능 모듈은 로그들로 분할 될 수 있고, 제 3 자에게 최초의 로그는 두 가지 유형의 레지스터
- 먼저 자 로그인 : 응용 프로그램 자체에서 제공하는 로그인 서비스를 제공합니다. 그것은 자신과 자신의 로그인 응용 프로그램, 그래서이 서비스와 크게 인증 과정을 촉진 할 응용 프로그램 서비스, 상호 신뢰에 로그인 때문입니다.
- 로그인 : 제 3 자 기관이 제공 한 응용 프로그램 로그인 서비스는 마이크로 편지, QQ를 통해 타사 사용자 계정 로그인의 사용은, Alipay의 계정 등등에 로그온 할 수 있습니다. 현재 업계 표준 사용하여 주요 인터넷 오픈 플랫폼의 대부분 의 OAuth 2.0 인증 코드 모드를 타사 로그인을 달성하기 위해.
사용자 인증 기술에 큰 차이가없는 자사 및 제 3 자에 로그인 로그인하지만, 인증 프로세스는 차이에게 있습니다. 특정 인증 과정은 아래 달성하기 위해 아키텍처의 차이를 토론하고.
2.1 인증
인터넷의 발전에 공통 인증 모드,
- 사용자 이름 및 암호
- SMS 확인 코드
- 2 차원 코드 스캔 모바일 애플리케이션
- 사용자 제스처
- 사용자와 관련된 일회성 암호를 기반으로 시계열
토론 용지를 용이하게하기 위해, 간단한 HTTP 기본 인증 (HTTP 기본 인증) 사용자가 로그온 방법, 즉 방법 사용자 이름과 암호를 사용합니다. 이상의 인증 방법은, 일반적으로 확장 인터페이스 ID 제공을 통해 달성 될 수있다.
2.2 라이센스
사용자가 성공적으로 로그인하면, 적절한 인증 정보를 얻을 수 있습니다.
인터넷 응용 프로그램 개발의 분야에서 구현 기술은 주로 다음과 같습니다 권한,
- 웹 서버를 통해 세션 메커니즘, 사용자의 인증 정보를 관리 할 수있는 액세스 세션
- 웹 브라우저를 통해 쿠키 메커니즘, 쿠키는 웹 사이트의 사용자 인증 정보를 유지
- 발행 인증 토큰 (토큰), 법적으로 유효한 토큰은 사용자의 인증 정보를 유지
모두 전면, 웹 개발의 일반적인 브라우저의 지원을 필요로한다. 모바일 및 다른 응용 프로그램이 쿠키 장면을 사용할 수없는 경우, 종종 달성하고 요청 헤더 방식으로 인증 토큰 정보를 전달하기 위해 사용될 수.
주문 승인 물품 지지체 웹 어플리케이션 및 모바일 애플리케이션에서,인가 정보가인가 토큰 (토큰)의 형태로 제공 할 웹 애플리케이션에 대하여, 쿠키의 요청에서 운반인가 토큰 모바일 애플리케이션 반면 경유하여 헤더를 운반 요청한다.
첫째 자 로그인을 달성하기 위해 2.3 아키텍처
그것은 자신의 사인에 구현, 그래서 서비스 및 응용 프로그램 서비스 사이에 로그온하기 때문에 크게 인증 과정을 촉진 것이다, 서로 신뢰할.
첫 번째 파티 장면 로그에서, 일반적으로 두 가지 방법으로 허가 할 수있다,
- 응용 프로그램이 브라우저를 통해 액세스 할 경우, 쿠키 도메인의 승인과 공유 할 수 있습니다
- 응용 프로그램이 브라우저 액세스하지 않거나 할 수없는 경우, 직접 쿠키 기술을 통해 사용자 이름과 암호에 의해 승인 교환 할 수 있습니다. 이 응용 프로그램 서비스는 신뢰할 수있는 응용 프로그램에 따라 전제 조건 사용자 이름 및 암호와 같은 중요한 정보를 얻을 수 있음을 유의해야한다.
코드 구현 (개발 예정)
간단한 프레임 워크는 다음을 달성하기 위해,
포함하는 단일 사인 아키텍처 구현에 필요한 구성 요소 및 기능도 밝은 적색 라인 및 사각형
- 싱글 사인 온 모듈 : 사용자 로그인 인터페이스를 제공, 이동하는 것이 가능 반환 발급 인증 토큰 (토큰), 체크섬 취소
- 웹 필터 : 그렇지 않으면 오류 메시지를 반환, 인증 토큰 요청을 획득하고 요청을 통해 합법적 있는지 확인합니다.
웹 애플리케이션의 경우, 쿠키가 길의 승인을 얻을 공유하여,로는 다음과 전체 프로세스의 상호 작용,
- 사용자는 브라우저를 통해 웹 서비스에 액세스
- 일반적인 웹 필터 점검 요청에서 백엔드 서비스, 요청, 다음 사용자가 로그온 할 수 있도록 사용자의 로그인 모듈로 이동 발견 된 인증 토큰이 아닌 경우
- 로그인이 성공하면 사용자 이름과 암호를 입력하는 사용자, 쿠키 인증 토큰은 브라우저에 저장됩니다
- 다시 사용자 액세스 페이지로 이동하는 사용자는 그 요청이 자동으로 인증 토큰 쿠키를 가져올 것이다
- 합법적이고 유효한, 백엔드 서비스에 액세스 할 수있는 사용자가, 그렇지 않으면 에러 메시지를 반환하는 경우 쿠키의 웹 필터 백엔드 서비스 검증 승인을 요청 토큰은 사용자가 다시 로그인하라는 메시지가 표시됩니다.
- 사용자가 로그 오프하면, 웹 응용 프로그램 서비스 인증 토큰은 쿠키를 삭제 브라우저에 저장 레디 스 토큰을 로그 오프한다.
모바일 애플리케이션의 경우, 사용자 이름과 암호의 방법으로 허가를 얻기로 다음과 전체 프로세스의 상호 작용,
- 사용자는 모바일 응용 프로그램을 열고, 응용 프로그램에 로그온하라는 메시지를 표시
- 로그인이 성공하면 사용자 이름과 암호를 입력하는 사용자는 토큰이 모바일 애플리케이션, 스토리지에 반환, 전화 응용 프로그램 저장 공간은 권한이 부여됩니다.
- 애플리케이션을 입력 한 후, 모바일 애플리케이션 액세스 백엔드 서비스는인가 토큰을 요청 헤더에서 운반
- 합법적이고 유효한 경우 인증 토큰의 검증에 대한 요청의 일반적인 웹 필터 헤더의 백엔드 서비스는, 사용자가 백엔드 서비스에 액세스하거나 로그온하라는 메시지가 표시 될 수 있습니다.
- 사용자가 로그 오프하면, 모바일 응용 프로그램이 인증 토큰 및 토큰 레디 스 취소를 제거합니다.
모바일 애플리케이션은 웹 애플리케이션을 좋아하지 않기 때문에, 브라우저 모드를 통해 쿠키가 자동으로 인증 정보, 모바일 응용 프로그램이 자체 보관 처리 및 인증 정보 요청을 필요로 실시한다.
2.4 아키텍처는 타사 로그인을 할 수 있습니다
첫 번째 참여자에 비해 로그인, 타사도 스페어를 사용자 계정을 등록하는 단계를 제거, 사용자 등 마이크로 편지, QQ, Taobao의 계정으로 직접에서 인기있는 타사 계정 로그를 사용할 수 있도록 가장 큰 장점 로그인하지만, 사용자 메모리 응용 프로그램은 암호 문제함으로써 사용자 액세스의 비용을 절감, 사용자의 빠른 사용을 촉진하는 계정.
타사 로그인의 경우, 현재 주요 인터넷 오픈 플랫폼들은 업계 표준의 OAuth 2.0 인증 코드 모드를 사용합니다. 의 OAuth 2.0 인증 코드 모드 및 자세한 내용은 다른 기사에서 논의 될 것이다, 여기가 확장되지 않습니다.
코드 구현 (개발 예정)
간단한 프레임 워크는 다음을 달성하기 위해,
단일 사인 아키텍처를 포함하여 구현에 필요한 구성 요소 및 기능도 밝은 레드 라인과 사각형,
- 의 OAuth 2.0 인증 서버 : 반환에게 인증 토큰을 달성 점프, 사용자 로그인 인증을 제공 (토큰) 발급, 검증 및 취소
- 토큰 인터페이스 : 클라이언트가 인증 코드를 통해 인증 토큰에 대한 대가로 호출
- 웹 필터 : 그렇지 않으면 오류 메시지를 반환, 인증 토큰 요청을 획득하고 요청을 통해 합법적 있는지 확인합니다.
어플리케이션, 웹 어플리케이션 및 모바일 두 가지 유형의 인증을 얻기 위해 실질적으로 동일한 방법으로 두 가지 종류가도이다.
웹 응용 프로그램의 상호 작용은 전체 프로세스를 다음,
- 用户通过浏览器访问Web服务
- 后端服务中一个通用的web filter校验请求，若发现请求中没有授权令牌，则跳转至第三方用户登录服务
- 在第三方登录服务中，用户输入用户名和密码，若登录成功，则跳转回web应用，并返回授权码
- Web应用将获取到的授权码，调用后端Token接口，该接口将根据授权码+应用ID+应用Secret，向第三方申请授权令牌，若一切正常，第三方颁发授权令牌给Web应用，Web应用将获取到的授权令牌存储在浏览器的cookie中。
- 将用户跳转回用户的初始访问页面，此时请求中cookie将自动带上授权令牌
- 后端服务的web filter校验请求cookie中的授权令牌，若合法且有效，则用户可以正常访问后端服务，否则返回错误消息，提示用户再次登录。
- 用户注销登录时，web应用服务将存储在浏览器cookie中的授权令牌清除，并注销redis中的令牌。
移动应用和web应用的流程类似，整个流程交互如下，
- 用户打开移动应用，应用提示用户登录，并将用户导向第三方登录服务
- 在第三方登录服务中，用户输入用户名和密码，若登录成功，则跳转回移动应用，并返回授权码给移动应用。
- 移动应用将获取到的授权码，调用后端Token接口，该接口将根据授权码+应用ID+应用Secret，向第三方申请授权令牌，若一切正常，第三方颁发授权令牌给移动应用，移动应用将获取到的授权令牌存储在手机上的应用存储空间。
- 进入应用后，移动应用访问后端服务，授权令牌携带在请求header中
- 后端服务中一个通用的web filter对请求header中的授权令牌进行校验，若合法且有效，则用户可以正常访问后端服务，否则提示用户登录。
- 用户注销登录时，移动应用将授权令牌清除，并注销redis中的令牌。
2.5 第一方登录和第三方登录的授权区别
第一方登录和第三方登录之间最大的区别在于授权流程。
第一方登录在用户被认证之后，即刻颁发授权令牌，应用服务一般无需介入授权流程。而第三方登录在用户认证之后，先颁发给授权码给应用服务，应用服务还需根据这个授权码去换取授权令牌，换句话说，应用服务需介入授权流程。
这里有个问题是，为什么在第三方登录中，应用服务会被介入授权流程？主要原因是在第三方登录场景中，除了用户需要被认证，应用服务本身也需要被认证。而在第一方登录场景，只需用户认证，应用服务本身是可信的，其无需被认证。
2.6 登录架构实现小结
为了对比上述两个登录架构实现的不同之处，下面将各自的特点小结为下表，
| 第一方登录架构 | 第三方登录架构 | |
|---|---|---|
| 登录功能 | 由己方提供 | 由第三方提供 使用第三方的用户账户 |
| 登录实现 | 通过http basic auth | OAuth 2.0授权码模式 |
| 应用是否可信 | 可信，应用可以接触用户密码等敏感信息，应用本身无需认证 | 不可信 |
| 应用是否需要认证 | 否 | 是 |
| 应用是否可以接触用户密码等敏感信息 | 是 | 否 |
| 授权过程 | 登录成功后颁发token | 1. 登录成功后返回授权码给应用 2. 应用根据授权码和应用ID换取token |
| Web页面的服务请求 | 通过cookie带上token | 通过cookie带上token |
| 移动应用的服务请求 | 通过header带上token | 通过header带上token |
3. 权限控制
在互联网应用开发中，安全控制在后端服务中实现。整个权限控制的过程一般会涉及到鉴权和权限控制两个环节。
鉴权的实现方式一般有两种，
- 通过授权服务器：由于授权令牌是由授权服务器颁发的，所以由授权服务器校验也是自然而然的事情。这种方式会导致授权服务器的访问热点问题，为了缓解热点，缓存是必要配置。
- 通过加解密：通过授权令牌的加解密方式，确认令牌的合法性。即，授权服务器颁发一个通过公钥加密的授权令牌，在校验的时候若能够通过私钥解密，则该令牌为合法令牌。这种方式有一个缺点是，一旦令牌注销失效后，信息无法及时通知到解密方。对令牌的注销时效性要求不高的场景下，可以使用这种方式，其大大缓解了授权服务器的访问热点问题。
若根据鉴权的架构方式，则可分为分布式和集中式两大类，
- 分布式：通过后端web服务的filter实现分布式控制，在各个服务应用的运行实例中进行鉴权
- 集中式：通过网关实现集中式控制，在访问流量的入口进行鉴权
鉴权后访问控制粒度从大到小有如下三种分类，
- Http方法级别
- API接口级别
- API实现级别
下面将对鉴权的架构实现和控制粒度进行详细讨论。
3.1 分布式鉴权架构
分布式鉴权的架构如下图，
在web应用开发中，可以通过web应用服务的filter功能，对所有请求中的授权令牌进行校验，实现分布式鉴权。分布式鉴权实现简单，可以快速实现并使用，但随着应用服务架构的水平和垂直扩展，filter的升级将会成为头痛的问题。
3.2 集中式鉴权架构
集中式鉴权的架构如下图，
通过网关，在访问流量的入口，对所有请求中的授权令牌进行校验，实现集中式鉴权。集中式鉴权减轻了应用服务的接入成本，但会增加了网关的性能负荷。
3.3 分布式和集中式鉴权的优缺点
分布式鉴权和集中式鉴权有各自的优缺点小结为下表，
| 分布式鉴权 | 集中式鉴权 | |
|---|---|---|
| 优点 | 简单，可以分散校验热点 | 应用服务接入成本低，方便鉴权管理 |
| 缺点 | filter版本升级困难，需要对所有应用服务进行依赖更新 | 需要网关的支持，并且鉴权操作将增加网关的性能负荷 |
| 应用场景 | 简单的互联网web应用开发 | 大型互联网web应用开发 |
3.4 访问控制的粒度
鉴权后就会得到请求访问的权限，接下来则是根据权限来控制请求访问的允许或禁止。
根据访问控制粒度从大到小，可划分出如下几个控制级别，
- Http方法级别
- API接口级别
- API实现级别
3.4.1 HTTP方法级别
若web应用服务是按照Restful的规范来开发接口服务，则可以根据Restful的定义对Http的不同方法实现不同的访问控制。
根据Restful的规范定义，Http方法具有如下安全性和幂等性的特点，
| HTTP方法 | Restful定义 | 安全性 | 幂等性 |
|---|---|---|---|
| GET | 获取资源 | 是 | 是 |
| POST | 创建资源 | 否 | 否 |
| PUT | 更新资源 | 否 | 是 |
| DELETE | 删除资源 | 否 | 是 |
| HEADER | 资源元信息 | 是 | 是 |
| OPTIONS | 是 | 是 |
表中，安全性和幂等性的概念如下,
- 安全性是指该方法不改变资源的状态，即不改变后台数据
- 幂等性是指该方法执行的同一操作多次，其结果保持一致
可以看到，对于安全的HTTP方法，比如GET操作，其访问控制可以宽松。而对于一些非安全操作，则需要根据不同权限来控制访问请求。在实际应用过程中，可以执行如下的权限控制规则，
- 匿名用户：可以执行GET请求
- 普通登录用户：可以执行GET、POST、PUT请求
- 管理员：可以执行所有类别请求
总的来说，根据Http请求的方法和URI进行访问控制。
3.4.2 API接口级别
这个权限控制的粒度深入到代码控制层（Controller），不同的权限，可以访问不同的API接口。
一个spring mvc的代码样例如下，
@Controller
public class TokenApp { @PreAuthorize("hasAuthority('ROLE_ADMIN')") public Principal getUserInfo(Principal me){ return me; } } 上面的代码表示，具有管理员角色的权限才能获取当前用户信息。
这个粒度的权限访问控制基本可以满足大多数应用场景需求。
3.4.3 API实现级别
在应用的实现级别进行控制，这个控制粒度非常细，其根据不同权限返回不一样的调用结果，例如，同样是查看学生列表，若是班主任，则返回一个班的学生列表，若是校长，则返回一个学校的学生列表。
4. 小结
本文主要从用户登录和权限控制两大功能方面梳理其架构实现，这些实现可以结合实际的应用场景，进行相应的匹配。
| 第一方登录 | 第三方登录 | |
|---|---|---|
| 分布式权限控制 | 1. 简单web应用场景 2. 登录服务和应用服务相互可信 3. 登录服务和应用服务同域，可以授权共享 |
1. 简单web应用场景 2. 登录服务和应用服务相互不可信 3. 登录服务和应用服务不同域，各自独立开发部署，无法授权共享 4. 应用和登录服务模块彻底解耦，通过跨域跳转实现用户登录。 |
| 集中式权限控制 | 1. 大型web应用场景，有网关组件部署 | 1. 大型web应用场景，有网关组件部署 2. 快速接入第三方用户 |