프런트엔드 및 백엔드 인증 방법에 대한 간략한 설명

일반적인 인증 메커니즘

HTTP는 상태 비저장 프로토콜입니다(트랜잭션 처리를 위한 메모리가 없으며 클라이언트와 서버 세션이 완료될 때마다 서버는 세션 정보를 저장하지 않습니다.): 각 요청은 완전히 독립적이며 서버는 현재 ID를 확인할 수 없습니다. 방문자의 정보로는 지난번 요청의 발송인과 이번 요청의 발송인이 동일인인지 알 수 없습니다. 따라서 세션을 추적(누가 나를 방문하는지 알기 위해)하려면 서버와 브라우저가 적극적으로 상태를 유지해야 하며, 이 상태는 이전 요청과 이후 요청이 동일한 브라우저에서 온 것인지 서버에 알리는 데 사용됩니다. 다양한 종류의 인증 방법이 발생합니다.

HTTP 기본 인증
세션 쿠키
토큰
OAuth

이 기사의 보너스로 주요 제조업체로부터 무료 Linux C/C++ 개발 학습 자료 패키지, 기술 비디오/코드 및 1,000개의 인터뷰 질문을 받을 수 있습니다(C++ 기초, 네트워크 프로그래밍, 데이터베이스, 미들웨어, 백엔드 개발/ 오디오 및 비디오 개발/Qt 개발/게임 개발/Linuxn 커널 및 기타 고급 학습 자료 및 최고의 학습 로드맵) ↓↓↓↓↓↓아래 참조↓↓기사 하단을 클릭하면 무료로 받을 수 있습니다↓↓

또한 인증과 승인의 구별에 주의해야 합니다. 하나는인증이고 다른 하나는승인. 인증은 자신이 본인임을 확인하는 것이고, 승인은 무언가를 할 수 있는 권한이 있는지 확인하는 것입니다. 모든 사람이 인증과 권한 부여 간의 관계를 더 잘 이해할 수 있도록 세 가지 상황을 설명하기 위해 각각 세 가지 예를 제공합니다.

인증만 하고 인증은 하지 않음애플리케이션에 로그인만 하고 다른 작업은 수행하지 않습니다. 이때는 인증은 필요하지 않고 인증만 수행됩니다.
인증 및 승인 모두제3자 애플리케이션을 사용하여 로그인할 때 인증을 위해 제3자 애플리케이션의 계정과 비밀번호를 입력할 뿐만 아니라 인증도 수행합니다. 본 애플리케이션은 제3자 로그인 애플리케이션에 등록된 개인정보 데이터 등을 열람합니다.
인증 없이 승인만미니 프로그램을 클릭하면 개인정보를 얻어야 하는데 이때는 아무런 인증 없이 미니 프로그램에 데이터만 승인하는 것과 같습니다. 결국 애플리케이션에서 내부적으로 작은 프로그램을 사용하는 경우 인증을 위해 로그인할 필요가 거의 없습니다.

각 인증 메커니즘의 프로세스 및 원리

인증과 승인이 관련되면 고려해야 할 문제는 상태 관리입니다. 소위 상태 관리는 일정 기간 동안 로그인한 후 액세스할 때마다 다시 로그인할 필요가 없음을 의미합니다. 따라서 개발자는 사용자의 로그인 상태를 유지하고 만료 시간을 설정하는 방법을 고려해야 합니다. 이 프로세스를 완료하려면 프런트엔드와 백엔드가 함께 작동해야 합니다.

몇 가지 일반적인 인증 및 권한 부여 방법의 프로세스와 원칙에 대해 간략하게 설명하겠습니다. 저는 단지 헛소리일 뿐이며 여러분의 조언을 환영합니다.

HTTP 기본 인증

이 인증 방법은 HTTP 프로토콜을 준수하는 브라우저에서 구현되는 기본 인증 방법으로, HTTP 프로토콜은 HTTP 서버가 클라이언트에서 사용자 식별을 수행할 수 있도록 하는 기본 인증 방법을 정의합니다.

기본 프로세스

Send a request : 클라이언트가 서버에 데이터를 요청하는데, 요청한 내용은 웹페이지일 수도 있고 ajax 비동기식 요청일 수도 있는데, 이때 클라이언트가 검증되지 않았다는 가정하에(서버가 검증하여 401을 반환할지 결정함), 클라이언트는 서버에 다음 요청을 제공합니다.

Get /index.html HTTP/1.0 
Host: www.google.com

서버는 401을 반환합니다: 서버는 클라이언트에게 확인 요청 코드 401을 보냅니다. WWW-Authenticate: Basic realm="google.com" 이 문장이 핵심입니다. 클라이언트가 없는 경우 사용자 이름과 비밀번호 입력 인터페이스는 팝업이 되지 않습니다.서버에서 반환되는 데이터는 대략 다음과 같습니다.

HTTP/1.0 401 Unauthorised 
Server: SokEvo/1.0 
WWW-Authenticate: Basic realm="google.com"
Content-Type: text/html 
Content-Length: xxx

클라이언트 팝업 창: http1.0 또는 1.1 사양을 준수하는 클라이언트가 401 반환 값을 받으면 사용자에게 사용자 이름과 비밀번호를 입력하라는 로그인 창이 자동으로 팝업됩니다. 이때 요청은 보류 상태이며, 사용자가 사용자 이름과 비밀번호를 입력하면 클라이언트는 Authorization 헤더와 함께 다시 요청을 보냅니다.
사용자는 사용자 이름과 비밀번호를 입력합니다: 비밀번호를 입력한 후 제출을 클릭하면 사용자 이름과 비밀번호가 Base64 암호화로 암호화되어 이전 요청 정보에 암호문이 삽입됩니다.그러면 클라이언트가 보낸 첫 번째 요청 정보는 다음과 같은 내용이 됩니다.

Get /index.html HTTP/1.0 
Host: www.google.com
Authorization: Basic xxxxxxx(base64 密文)
// 加密过程是浏览器默认的行为，不需要我们人为加密，我们只需要输入用户名密码即可。

서버 측 복호화: 서버는 위의 요청 정보를 받은 후 Authorization 필드 뒤의 사용자 정보를 꺼내서 복호화하고, 복호화된 사용자 이름과 비밀번호를 사용자 데이터베이스와 비교하여 확인합니다. 사용자 이름과 비밀번호가 올바른 경우, 서버는 요청에 따라 요청된 리소스를 클라이언트에 보냅니다.

장점: 간단하고 편리하며 호환성이 좋습니다.

단점: TLS/SSL을 사용하지 않으면 정보가 쉽게 유출되고 안전하지 않으며, 로그아웃이 불가능하고 브라우저나 탭만 닫을 수 있습니다.

세션 쿠키

본 인증 방식은 서버측 Session과 브라우저(클라이언트) Cookie를 이용하여 구현한 Front-End 및 Back-End 통신 인증 모드입니다. HTTP 프로토콜은 상태 비저장 프로토콜입니다. 서버는 어떤 브라우저가 자신에게 액세스하고 있는지 알지 못하므로 서버가 서로 다른 브라우저를 구별할 수 있도록 하려면 식별자가 필요합니다. 쿠키는 서버와 클라이언트 사이의 상태를 관리하는 식별자입니다. 쿠키의 원리는 브라우저가 처음으로 서버에 요청을 보낼 때 서버가 응답 헤더에 Set-Cookie 필드를 설정하고, 브라우저가 응답을 받으면 쿠키를 설정하여 저장하는 것입니다. 다음에 브라우저가 서버에 요청을 보내면 쿠키 필드가 요청 헤더에 자동으로 추가되고 서버는 다른 브라우저를 구별하기 위해 쿠키를 받게 됩니다. 물론, 최초 방문 시 이 쿠키와 특정 사용자 간의 대응 관계가 서버 측에 존재해야 하며, 이 경우 세션이 필요합니다. 또한, 쿠키의 만료시간을 설정해 두시기 바랍니다.만료시간을 설정하지 않고 브라우저를 닫으면 쿠키는 사라지며, 만료시간을 설정하면 로컬디스크에 저장됩니다. 서버는 세션 구성도 기억하는데, 특히 분산 서버의 경우 인증 메커니즘에서 쿠키 공유, 세션 공유 등의 문제를 고려해야 합니다. 세션(Session)은 세션을 의미하며, 브라우저가 서버에 처음 접속하면 서버는 세션을 생성하고 해당 세션에 브라우저를 식별하는 정보를 저장합니다. 쿠키와 차이점은 세션은 서버 측에 캐시되고 쿠키는 클라이언트 측에 캐시된다는 점입니다. 둘 다 HTTP 프로토콜의 상태 비저장 결함을 보완하기 위해 서버 측에서 생성됩니다. 요청이 서버에 도달할 때마다 해당 요청에 포함된 사용자 ID가 세션에 존재하는지 먼저 확인하여 존재하면 인증에 성공한 것이고, 그렇지 않으면 인증에 실패한 것입니다.

기본 프로세스

서버가 클라이언트의 첫 번째 액세스를 수락하면 서버 측에 Seesion을 생성한 다음 해당 Sesion을 저장합니다(우리는 Sesion을 메모리나 Redis에 저장할 수 있으며 후자가 권장됨). 그런 다음 이 세션에 대한 고유 식별자를 생성합니다. . 문자열 세션 ID(sid).
클라이언트가 sid를 수정하는 것을 방지하려면 비밀 키(사용자 정의)로 sid에 서명하세요. (비필수 단계) sid를 생성한 후, sid를 사용자 정보와 매핑하여 서버에 저장하고, 마지막으로 이 고유 식별 문자열을 응답 헤더에 심어(set-cookie)줍니다.
브라우저가 요청 응답을 받으면 응답 헤더를 구문 분석한 다음 로컬 쿠키에 sid를 저장합니다. 브라우저는 다음 http 요청의 요청 헤더에 있는 도메인 이름 아래에 쿠키 정보를 가져옵니다.
서버가 나중에 클라이언트 요청을 수락하면 요청 헤더 쿠키의 sid를 구문 분석한 다음 이 sid를 사용하여 서버에 저장된 클라이언트의 세션을 찾아 요청이 합법적인지 확인합니다.
후속 요청에서 서버는 항상 SID를 기반으로 인증하고, 인증이 통과되면 처리를 계속합니다. 사용자가 로그아웃하면 서버와 클라이언트 모두 세션을 삭제합니다.

장점: 간단하고 편리하며 브라우저가 자동으로 가져옵니다. 매번 비교를 위해 데이터베이스에서 데이터를 가져올 필요가 없습니다(SID가 서버에 저장되지 않은 경우). 사용자 로그아웃 및 로그인을 쉽게 관리할 수 있습니다(삭제/추가). 세션).

단점 : 모바일단말기, PC단말기 등 브라우저 없이는 사용할 수 없음, 세션이 서버측에 저장되어 서버 오버헤드가 증가함, sid가 서버측에 존재하기 때문에 누군가 sid를 획득하면 , 크로스 사이트 요청 위조(CSRF) 공격에 취약합니다.), 우리는 HttpOnly를 설정할 수 있습니다(스크립트는 로컬에 저장된 sid를 읽을 수 없으므로 XSS 주입이 쿠키에서 sid를 얻지 못하게 하여 공격을 위조할 수 있습니다). 보안을 강화하기 위해 보안을 true(HTTPS 사용)로 설정합니다. 분산 서버에서는 세션과 같은 구성을 공유해야 하므로 로드 밸런싱 및 클러스터 수평 확장 기능이 제한됩니다.

세션도 쿠키 메커니즘에 의존합니다. 쿠키 인증은 쿠키보다 안전할 뿐만 아니라 세션의 다른 단점도 거의 모두 가지고 있습니다. 하지만 약간의 차이가 있으며 세션 쿠키의 인증 방법은 쿠키 인증만 사용하는 것보다 조금 더 많습니다. 세션은 쿠키보다 안전하며 세션은 서버 측에 저장되고 쿠키는 클라이언트 측에 저장됩니다. 쿠키는 문자열 데이터 저장만 지원합니다. 다른 유형의 데이터를 설정하려면 이를 문자열로 변환해야 합니다. 세션은 모든 데이터 유형을 저장할 수 있습니다. 쿠키는 우리가 자주 사용하는 기본 로그인 기능처럼 오랫동안 유지되도록 설정할 수 있습니다. 세션은 일반적으로 만료 시간이 짧으며 클라이언트가 닫히거나(기본적으로) 세션 시간이 초과되면 만료됩니다. 단일 쿠키에 저장되는 데이터는 4K를 초과할 수 없으며 세션은 쿠키보다 훨씬 많은 데이터를 저장할 수 있지만, 방문 횟수가 너무 많으면 서버 리소스를 너무 많이 차지하게 됩니다.
쿠키 인증의 기본 프로세스

토큰

토큰 승인

토큰이라고도 합니다. 본질적으로 의미없는 문자열입니다. 일반적으로 요청 헤더에 배치됩니다. 요청 헤더 키는 일반적으로 Authorization입니다. 물론 서버와 동의하여 다른 값으로 사용자 정의할 수도 있습니다. 서버가 요청 헤더에서 토큰을 얻을 수 있는 한. 토큰 인증 등장의 가장 큰 특징은 로그인 인증이 더 이상 쿠키 메커니즘에 의존하지 않는다는 점이며, 요청 헤더에 토큰을 배치함으로써 쿠키 메커니즘으로 인한 단점이 자연스럽게 제거됩니다.

클라이언트는 사용자 이름과 비밀번호를 사용하여 로그인을 요청합니다.
서버는 사용자 이름과 비밀번호를 확인하라는 요청을 받습니다.
성공적으로 검증되면 서버는 사용자 지정 규칙에 따라 토큰을 발급한 다음 클라이언트에 토큰을 보냅니다.
클라이언트는 토큰을 받은 후 쿠키나 LocalStorage 등에 토큰을 저장할 수 있습니다.
클라이언트가 서버에 리소스를 요청할 때마다 서버에서 발행한 토큰을 가져와서 요청 헤더 Authorization에 넣어야 합니다.
서버는 요청을 받은 후 클라이언트의 요청에 포함된 Token을 검증하고, 검증에 성공하면 요청한 데이터를 클라이언트에게 반환(발행된 Token을 데이터베이스에서 쿼리하고 사용자 데이터를 쿼리)하며, 실패하면 401 오류 코드를 반환하고 인증에 실패했습니다.

장점: 토큰 인증은 쿠키에 국한되지 않고 동일 출처 정책의 영향을 받지 않으며 요청 헤더의 특정 필드에 지정하여 애플리케이션에서 사용할 수 있으며 쿠키를 사용하지 않으면 공격자가 토큰이 어디에 있는지 추측할 수 없습니다. 사용자의 토큰은 로컬에 저장되며 요청을 제출할 때 서버가 읽을 수 있도록 요청 헤더의 특정 필드에만 배치됩니다(스크립트로 읽을 수 없는 추천자를 얻는 것과 유사). CSRF를 피할 수 있습니다. 어느 정도 공격을 합니다.

단점: 암호화 및 암호 해독 소비로 인해 토큰 인증은 Session-Cookie보다 성능이 더 많이 소모되고, 토큰은 sessionId보다 크고 더 많은 대역폭을 차지하며, 토큰은 데이터베이스에서 사용자 정보를 쿼리해야 하므로 데이터베이스 압력이 증가합니다.

JWT(JSON 웹 토큰)

각 요청에는 데이터베이스의 사용자 정보를 쿼리하기 위한 토큰이 필요하기 때문에 데이터베이스에 대한 부담이 너무 큽니다. 토큰에 사용자 정보가 담겨 있으면 요청 시마다 데이터베이스에 접근할 필요 없이 토큰에서 사용자 정보와 사용자 로그인 상태를 직접 파싱해 검증할 수 있는 것이 바로 JWT이다. 브라우저에 반환되는 토큰은 사용자 정보가 포함된 암호화된 문자열입니다. JWT의 전체 이름은 Json Web Token입니다. 실제로 이는 사용자 정보를 전달하는 토큰으로 이해되는 특수 토큰입니다. 따라서 JWT 인증과 토큰 인증은 본질적으로 동일합니다. 단, 토큰 인증을 위한 사용자 정보는 데이터베이스에서 확인합니다. JWT 인증을 위한 사용자 정보는 토큰에서 직접 구문 분석됩니다.

JWT 구성

머리글

Header 부분은 그림과 같이 JWT의 메타데이터를 기술하는 JSON 객체입니다. 위 코드에서 alg 속성은 서명 알고리즘(알고리즘)을 나타내며, 기본값은 HMAC SHA256(HS256으로 작성)입니다. typ 속성은 이 토큰의 유형을 나타냅니다. JWT 토큰은 JWT로 균일하게 작성됩니다. 마지막으로 Base64URL 알고리즘을 사용하여 위 JSON 개체를 문자열로 변환합니다(자세한 내용은 아래 참조).

유효 탑재량

페이로드 부분은 전송해야 하는 실제 데이터를 저장하는 데 사용되는 JSON 개체이기도 합니다. JWT는 선택을 위해 7개의 공식 필드를 지정합니다.

iss (issuer)：签发人
exp (expiration time)：过期时间
sub (subject)：主题
aud (audience)：受众
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号
除了官方字段，你还可以在这个部分定义私有字段，比如用户名、用户昵称、权限、部门等等。
注意，JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。
这个 JSON 对象也要使用 Base64URL 算法转成字符串。

서명

서명 부분은 데이터 변조를 방지하기 위해 처음 두 부분의 서명입니다. 먼저 비밀을 지정해야 합니다. 이 키(사용자 정의)는 서버에만 알려져 있으며 사용자에게 유출될 수 없습니다. 그런 다음 Header에 지정된 서명 알고리즘(기본값은 HMAC SHA256)을 사용하여 다음 수식에 따라 서명을 생성합니다. HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) 서명을 계산한 후 Header, Payload, Signature 세 부분을 문자열로 담고 각 부분을 로 구분하여 사용자에게 반환합니다.

Base64URL 알고리즘

앞서 언급했듯이 Header와 Payload를 직렬화하는 알고리즘은 Base64URL입니다. 이 알고리즘은 기본적으로 Base64 알고리즘과 유사하지만 몇 가지 사소한 차이점이 있습니다. JWT는 토큰이며 경우에 따라 URL에 배치될 수 있습니다(예: http://api.example.com/?token=xxx). Base64에는 URL에서 특별한 의미를 갖는 +, /, = 세 개의 문자가 있으므로 이를 바꿔야 합니다. =는 생략되고, +는 -로 바뀌고, /는 _로 대체됩니다. 이것은 Base64URL 알고리즘입니다.

기본 프로세스

위의 내용을 이해한 후, 과정에 대해 간략하게 이야기해보겠습니다.

기본적인 프로세스는 토큰과 동일하지만, 발행되는 토큰의 내용이 다릅니다.
JWT는 사용자 정보를 저장한다고 앞서 언급했으므로 우리가 해야 할 주요 작업은 다음과 같습니다. 클라이언트는 사용자 이름과 비밀번호를 사용하여 로그인을 요청하고, 서버는 사용자 이름과 비밀번호를 확인하라는 요청을 받습니다. 검증에 성공하면 서버는 사용자 정의 키와 사용자 정보를 기반으로 토큰을 발급한 후 클라이언트에 토큰을 보냅니다. 클라이언트는 토큰을 받은 후 쿠키나 LocalStorage 등에 토큰을 저장할 수 있습니다. 클라이언트가 서버에 리소스를 요청할 때마다 서버에서 발급한 Token을 가져와 Authorization 요청 헤더에 넣어야 하며, 물론 쿠키에 넣을 수도 있지만 도메인 간은 불가능합니다. Authorization: Bearer

다시 채우다

JWT는 기본적으로 암호화되지 않지만 암호화할 수도 있습니다. 원본 토큰을 생성한 후 키를 사용하여 다시 암호화할 수 있습니다. (프런트 엔드에서 토큰의 관련 정보를 사용해야 하는 경우 인코딩 규칙을 알려주세요.)
암호화 없이는 비밀 데이터를 JWT에 쓸 수 없습니다.
JWT는 인증뿐만 아니라 정보 교환에도 사용될 수 있습니다. JWT를 효과적으로 사용하면 서버가 데이터베이스를 쿼리하는 횟수를 줄일 수 있습니다.
JWT의 가장 큰 단점은 서버가 세션 상태를 저장하지 않기 때문에 사용 중에 토큰을 취소하거나 토큰의 권한을 변경할 수 없다는 점입니다. 즉, JWT가 한번 발급되면 서버가 추가 로직을 배포하지 않는 한 만료될 때까지 항상 유효하지만, 키와 파싱 암호화 로직이 모두 코드에 들어있기 때문에 분산 서버 관리가 용이하다는 장점도 있습니다. .
JWT 자체에는 인증 정보가 포함되어 있으며, 일단 유출되면 누구나 토큰에 대한 모든 권한을 얻을 수 있습니다. 도난을 줄이기 위해서는 JWT의 유효기간을 상대적으로 짧게 설정해야 합니다. 더 중요한 일부 권한의 경우 사용자가 해당 권한을 사용할 때 다시 인증을 받아야 합니다.
도난을 줄이기 위해 JWT는 HTTP 프로토콜을 사용하여 일반 코드로 전송해서는 안 되며, HTTPS 프로토콜을 사용하여 전송해야 합니다.
JWT의 유효기간은 상대적으로 짧게 설정되어야 하므로 로그인 상태 정보 갱신 문제가 발생한다. 예를 들어, 토큰의 유효 기간을 1시간으로 설정한 경우, 1시간 후에도 사용자가 여전히 애플리케이션에 남아 있다면 당연히 사용자가 이때 다시 로그인할 것이라고 기대할 수는 없습니다. 현재 사용 가능한 솔루션은 사용자가 요청할 때마다 새 토큰을 반환하고 프런트 엔드에서는 이 새 토큰을 사용하여 이전 토큰을 대체하여 요청이 있을 때마다 토큰의 유효 기간이 새로 고쳐지는 것입니다. 그러나 이를 위해서는 빈번한 토큰 생성이 필요합니다. 또 다른 해결책은 사용자가 요청할 때마다 토큰이 만료되는 데 걸리는 시간을 결정하고 토큰이 만료되려고 할 때 새 토큰을 반환하는 것입니다. 프론트엔드가 매번 요청 헤더를 자체적으로 운영하고 싶지 않다면 쿠키에 넣어두어도 되는데, 쿠키를 설정하고 http-only와 HTTPS만 설정하면 됩니다.
사용자가 능동적으로 로그아웃하는 경우 JWT는 사용자의 활성 로그아웃을 지원하지 않으며, 클라이언트는 다른 곳에서 토큰을 사용하여 계속 정상적으로 액세스할 수 있습니다. 로그아웃을 지원하기 위해 서버의 Redis 블랙리스트에 토큰을 추가하거나 로그아웃 시 데이터베이스 저장소를 설정할 수 있습니다.

OAuth

OAuth 프로토콜은 사용자 리소스 인증을 위한 안전하고 개방적이며 간단한 표준을 제공합니다. 이전 인증 방법과의 차이점은 OAuth 인증은 제3자가 사용자의 계정 정보(예: 사용자 이름 및 비밀번호)에 접근하는 것을 허용하지 않는다는 것입니다. 비밀번호 인증이므로 OAuth는 안전합니다.동시에 어떤 제3자라도 OAuth 인증 서비스를 사용할 수 있고, 어떤 서비스 제공자라도 자체 OAuth 인증 서비스를 구현할 수 있으므로 OAuth가 공개됩니다. OAuth 인증 서비스를 제공하는 일반적인 공급업체에는 Alipay, QQ, WeChat, Weibo, Github 등이 있습니다. OAuth 프로토콜에는 1.0과 2.0의 두 가지 버전이 있습니다. 심각한 보안 취약점으로 인해 비활성화된 1.0에 비해 버전 2.0의 전체 인증 확인 과정은 더욱 간단하고 안전하며 현재 가장 중요한 사용자 인증 및 권한 부여 방법입니다.

JWT와의 차이점OAuth2.0은 QQ를 사용하여 타사 계정에 로그인할 때 사용되는 인증 프레임워크(인증 프로세스 개념)입니다. 앱 . JWT는 프론트엔드와 백엔드가 분리되어 있어 백엔드 API만 간단하게 보호해야 할 때 사용하는 인증 프로토콜(인증 방식)입니다. 어떤 방법을 사용하든 데이터 보안을 보장하려면 HTTPS를 사용해야 합니다.

기본 프로세스

인증 요청(타사 애플리케이션이 적법한지 확인): 클라이언트(타사 애플리케이션)가 OAuth 서비스 제공자에게 승인되지 않은 RequestToken을 요청합니다. 즉, RequestToken URL에 대한 요청이 이루어집니다. OAuth 서비스 제공자는 사용자의 요청에 동의하고 oauth_token 및 해당 을 발급합니다. 사용자 oauth_token_secret 및 사용자에게 반환됩니다.
사용자 동의(사용자 동의 여부 확인) : 사용자는 자신이 승인한 RequestToken을 OAuth 서비스 제공자에게 요청합니다. 즉, UserAuthorization URL에 대한 요청을 시작하고 이전 단계에서 서비스 공급자가 발급한 승인되지 않은 oauth_token 및 oauth_token_secret을 전달합니다. OAuth 서비스 제공자는 사용자에게 웹페이지를 통한 로그인을 요구하고 인증을 완료하도록 안내합니다.
AccessToken 대신(타사 애플리케이션에 AccessToken&RefreshToken(선택 사항) 제공): RequestToken이 인증된 후 사용자는 AccessToken URL에 대한 요청을 시작하고 이전 단계에서 승인된 RequestToken AccessToken 및 RefreshToken과 교환 . OAuth 서비스 제공자는 사용자의 요청에 동의하고 AccessToken과 해당 키를 발급하여 사용자에게 반환합니다.
리소스 교환에 AccessToken 사용(타사 애플리케이션은 AccessToken을 통해 사용자가 승인한 관련 리소스를 얻음): 사용자는 나중에 이전 단계에서 반환된 AccessToken을 사용하여 사용자가 승인한 리소스에 액세스할 수 있습니다. AccessToken을 사용하여 리소스를 교환하지 못했습니다. RefreshToken을 사용하여 새 AccessToken

OAuth2.0은 4가지 인증 모드를 제공하며, 개발자는 자신의 비즈니스 상황에 따라 자유롭게 선택할 수 있습니다.

인증 코드 부여
암시적 부여 모드(간소화 모드) (암시적 부여)
비밀번호 인증 모드(리소스 소유자 비밀번호 자격 증명 부여)
클라이언트 자격 증명 부여

OAuth2.0과 4가지 모드를 이해하려면 Ruan Yifeng 선생님의 소개를 참조하세요.

싱글 사인온(SSO) 확장

JWT 싱글 사인온(SSO) 프로세스

세션 싱글 사인온(SSO) 프로세스

이 기사의 보너스로 주요 제조업체로부터 무료 Linux C/C++ 개발 학습 자료 패키지, 기술 비디오/코드 및 1,000개의 인터뷰 질문을 받을 수 있습니다(C++ 기초, 네트워크 프로그래밍, 데이터베이스, 미들웨어, 백엔드 개발/ 오디오 및 비디오 개발/Qt 개발/게임 개발/Linuxn 커널 및 기타 고급 학습 자료 및 최고의 학습 로드맵) ↓↓↓↓↓↓아래 참조↓↓기사 하단을 클릭하면 무료로 받을 수 있습니다↓↓