OAuth2-Server-php를 사용하여 Yii 프레임워크에 OAuth2 서버 구축
- WBOY원래의
- 2016-08-18 08:57:521048검색
http://www.cnblogs.com/ldms/p/4565547.html에서 가져온 원본 텍스트
Yii에는 사용할 수 있는 확장이 많이 있습니다. Yii 공식 홈페이지에서 제공되는 OAuth 관련 확장을 확인한 결과 OAuth2 클라이언트 확장을 여러 개 찾았지만 OAuth2 서버로 사용할 수 있는 확장은 찾지 못했습니다. Yii는 잘 구성되어 있고 쉽게 확장 가능한 프레임워크이기 때문에 다른 PHP OAuth2 서버 구현과 통합될 수 있습니다. OAuth.net/2/ 공식 웹사이트에는 PHP로 구현된 여러 OAuth2 서버가 제공됩니다. 여기서 첫 번째 OAuth2-Server-php는 Yii 프레임워크의 OAuth2 서버 확장으로 사용됩니다. 일부 필요한 통합 작업이 필요하며 주로 클라이언트 액세스를 허용하고 access_token을 발행하는 등의 클래스를 작성합니다.
1부: 데이터베이스 준비
OAuth2-Server-php에서 사용하는 데이터베이스 구조는 Github의 oauth2-server-php README.md에서 제공하는 테이블 구조(Schema)를 채택한 5가지가 있습니다. 테이블:
mysql> show tables;
+-------------+
| Tables_in_oauth2 |
+------------+
oauth_access_token |
| oauth_client |
| oauth_refresh_token |
| 사용자 |
+-------------+
5행 in set ( 0.00 sec)
각 테이블의 이름은 테이블에서 액세스되는 내용을 설명합니다. 테이블 이름은 사용자 정의할 수 있습니다. 사용자 정의 위치는 OAuth2/Storage/Pdo의 48행 config 배열입니다. .php, 여기서 사용하기 때문에 데이터베이스는 mysql이므로 수정해야 할 것은 Pdo입니다. Redis 등 다른 스토리지 솔루션을 사용하는 경우 해당 파일을 직접 수정하면 됩니다. 여기서 데이터베이스 이름은 모두 단수형입니다.
다음 SQL 문을 사용하여 5개의 테이블을 생성하고 테스트 클라이언트를 추가합니다.
######################## ######
### oauth2 테이블
##########################
`oauth_client`가 있으면 테이블 삭제;
`oauth_access_token`이 있으면 테이블 삭제;
`oauth_authorization_code`가 있으면 테이블 삭제;
`oauth_refresh_token`이 있으면 테이블 삭제;
` 사용자가 있으면 테이블 삭제 `;
CREATE TABLE `oauth_client` (
`client_id` VARCHAR(80) NOT NULL,
`client_secret` VARCHAR(80) NOT NULL,
`redirect_uri` VARCHAR(2000 ) NOT NULL,
CONSTRAINT client_id_pk PRIMARY KEY (client_id)
);
CREATE TABLE `oauth_access_token` (
`access_token` VARCHAR(40) NOT NULL,
`client_id` VARCHAR (80) NOT NULL,
`user_id` VARCHAR(255),
`expires` TIMESTAMP NOT NULL,
`scope` VARCHAR(2000),
CONSTRAINT access_token_pk PRIMARY KEY(access_token)
);
CREATE TABLE `oauth_authorization_code` (
`authorization_code` VARCHAR(40) NOT NULL,
`client_id` VARCHAR(80) NOT NULL,
`user_id` VARCHAR( 255 ), `redirect_uri` varchar(2000),
`` `` `` `` `` 🎜 2000),
제약 auth_pk 기본 키(Authori ZATION_CODE)
);
CREATE TABLE `oauth_refresh_token` (
`refresh_token` VARCHAR(40) NOT NULL,
`client_id` VARCHAR(80) NOT NULL,
`user_id` VARCHAR(255),
`expires` TIMESTAMP NOT NULL,
`scope` VARCHAR(2000),
CONSTRAINT Refresh_token_pk PRIMARY KEY (refresh_token)
);
--
CREATE TABLE ` user ` (
`user_id` INT(11) NOT NULL AUTO_INCREMENT,
`username` VARCHAR(255) NOT NULL,
`password` VARCHAR(2000),
`first_name` VARCHAR(255) ,
`last_name` VARCHAR(255),
CONSTRAINT user_pk PRIMARY KEY (user_id)
);
-- 테스트 데이터
INSERT INTO oauth_client(client_id, client_secret, 리디렉션_uri)
VALUES("testclient", "testpass", "http://fake/");
INSERT INTO 사용자(사용자 이름, 비밀번호) , 이름, 성)
VALUES ('rereadyou', '8551be07bab21f3933e8177538d411e43b78dbcc', 'bo', 'zhang');
2부: 인증 체계 및 구현
OAuth2 RFC 6749 사양은 네 가지 기본 인증 체계를 제공하며 다음은 이러한 네 가지 인증 체계 각각과 이 구현에서 사용되는 방법을 설명합니다.
첫 번째 인증 방법 : Authorization Code Grant (Authorization Code Authentication)
Authorization Server를 클라이언트와 리소스 소유자 간의 중개자로 사용하여 Authorization Code를 획득합니다. 클라이언트는 리소스 소유자에게 직접 권한 부여를 요청하는 대신 리소스 소유자를 권한 부여 서버(RFC 2616에 정의된 사용자 에이전트를 통해)로 연결한 다음 권한 부여 코드를 사용하여 리소스 소유자를 클라이언트로 다시 연결합니다.
리소스 소유자에게 인증 코드를 사용하여 클라이언트로 돌아가도록 지시하기 전에 인증 서버는 리소스 소유자를 식별하고 그의 인증을 얻습니다. 리소스 소유자는 권한 부여 서버로만 인증하기 때문에 리소스 소유자의 자격 증명을 클라이언트와 공유할 필요가 없습니다.
인증 코드는 클라이언트의 신원을 확인하는 기능, 리소스 소유자의 사용자 에이전트를 통해 액세스 토큰을 전달하여 잠재적으로 노출되는 대신 클라이언트에 직접 전송하는 등 몇 가지 중요한 보안 이점을 제공합니다. 다른 사람(리소스 소유자 포함)에게
인증 코드 권한 유형은 액세스 토큰 및 새로 고침 토큰을 얻는 데 사용되며 기밀 클라이언트에 최적화되어 있습니다. 이는 리디렉션 기반 프로세스이므로 클라이언트는 리소스 소유자의 사용자 에이전트(일반적으로 웹 브라우저)와 상호 작용할 수 있어야 하며 리디렉션을 통해 인증 서버로부터 들어오는 요청을 받을 수 있어야 합니다.
인증 코드 부여 프로세스(웹 서버 흐름이라고도 함)는 다음과 같습니다.
+----------+
| 리소스 |
|
| ---------------+
| +----(A)-- & 리디렉션 URI ---->| 사용자- | 인증 |
| 에이전트 +----(B)-- 사용자 인증 --->| +----(C)- | -<| v ) (C) | ---' | 🎜> | 클라이언트 |
|<---(E)----- 액세스 토큰 --------- -------- --'
+---------+ (선택적 새로 고침 토큰 포함)
참고: (A), (B) 단계를 설명하고 (C)의 직선은 다음과 같습니다. 사용자 에이전트를 통과하면서 두 부분으로 나뉩니다.
그림 1: 인증 코드 흐름
그림 1에 표시된 흐름에는 다음 단계가 포함됩니다.
(A) 클라이언트는 리소스 소유자의 사용자 에이전트를 인증 끝점 프로세스로 보내는 것으로 시작합니다. . 클라이언트에는 클라이언트 ID, 요청 범위, 로컬 상태 및 액세스가 허용(또는 거부)되면 권한 부여 서버가 사용자 에이전트를 다시 보낼 리디렉션 URI가 포함됩니다.
(B) 인증 서버는 (사용자 에이전트를 통해) 리소스 소유자의 신원을 확인하고 리소스 소유자가 클라이언트의 액세스 요청을 승인하거나 거부하는지 여부를 결정합니다.
(C) 리소스 소유자가 액세스 권한을 부여한다고 가정하면 인증 서버는 이전에 제공된 리디렉션 URI를 사용하여(요청 시 또는 클라이언트 등록 시) 사용자 에이전트를 클라이언트로 다시 리디렉션합니다. 리디렉션 URI에는 클라이언트가 이전에 제공한 인증 코드와 로컬 상태가 포함됩니다.
(D) 클라이언트는 이전 단계에서 받은 인증 코드를 포함하여 인증 서버의 토큰 엔드포인트에 액세스 토큰을 요청합니다. 요청할 때 클라이언트는 권한 부여 서버를 통해 인증합니다. 클라이언트에는 인증을 위한 인증 코드를 얻는 데 사용되는 리디렉션 URI가 포함되어 있습니다.
(E) 인증 서버는 클라이언트를 인증하고 인증 코드를 확인한 후 수신된 리디렉션 URI가 (C) 단계에서 클라이언트를 리디렉션하는 데 사용된 URI와 일치하는지 확인합니다. 전달되면 인증 서버는 액세스 토큰과 선택적 새로 고침 토큰으로 응답합니다.
프로세스 구현:
1. 클라이언트 앱은 앱 ID를 사용하여 인증 코드를 얻습니다.
www.yii.com/oauth2/index.php?r=oauth2/authroize&response_type=code&client_id= testclient&state =xyz
반환: $authcode = 인증 코드.
팁: 인증 코드는 30초 후에 만료됩니다. OAuth2/ResponseType/AuthorizationCode.php에서 AuthorizationCode 클래스의 생성자 구성 매개변수를 수정하여 사용자 정의할 수 있습니다. Authorization_code 유효 시간입니다.
Client_id는 본 서버에 미리 등록된 애플리케이션 이름으로, 클라이언트 관리 범위에 속합니다.
이 단계에서는 사용자(리소스 소유자)가 OAuth2 서버에 로그인하여 인증 작업을 완료해야 합니다. 사용자 로그인은 사용자 관리의 범주에 속하며 OAuth2 서버에 작성해야 하는 기능이 아닙니다.
로그인 후 사용자는 클라이언트 앱에서 열 수 있는 작업(인증)을 선택할 수 있습니다.
바인딩 프로세스의 이 단계에서는 보안 관점에서 사용자가 바인딩을 확인하기 위해 사용자 이름과 비밀번호를 다시 입력해야 합니다. 바인딩을 위해 현재 사용자 세션을 직접 읽지 마세요.
2. access_token 가져오기:
클라이언트 앱은 access_token과 교환하여 인증 코드를 사용합니다
컬 -u testclient:testpass www.yii.com/oauth2/index.php?r=oauth2/token -d "grant_type=authorization_code&code=$authcode
반환:
성공:
{" access_token":"aea4a1059d3194a3dd5e4117bedd6e07ccc3f402",
"expires_in":3600,
"token_type":"bearer",
"scope":null,
"refresh_token":"269a623f5417 1e8598b1852eefcf115f4882b820"
}
> 팁: 이 단계에서는 access_code 대신 client_id, client_secret 및 이전 단계에서 얻은 Authorization_code를 사용해야 합니다.
Access_tokne은 3600s에 유효하고,refresh_token은 1209600s에 유효하며 다음에서 구성할 수 있습니다. OAuth2/ResponseType/AccessToken.php의 AccessToken 클래스는 함수 구성에서 수정합니다. 새로 고침 토큰 발행을 지원하며 작업의 특정 리디렉션 URI를 알고 있는 공용 클라이언트에 최적화되어 있습니다. 이러한 클라이언트는 일반적으로 스크립팅 언어를 사용하여 브라우저에서 구현됩니다. JavaScript
이는 리디렉션 기반 Directed 흐름이므로 클라이언트는 리소스 소유자의 사용자 에이전트(일반적으로 웹 브라우저)와 상호 작용할 수 있어야 하며 인증 서버에서 들어오는 요청을 받을 수 있어야 합니다( 리디렉션을 통해).
클라이언트가 Authorization 토큰과 Access Token을 별도로 요청하는 Authorization Code 권한 유형과 달리 클라이언트는 Authorization 요청의 결과로 Access Token을 받습니다.
암시적 권한 유형에는 클라이언트 인증이 포함되지 않지만 리소스 소유자 존재 및 리디렉션 URI 등록에 의존합니다. 액세스 토큰은 리디렉션 URI로 인코딩되므로 동일한 장치에 있는 리소스 소유자 및 기타 애플리케이션에 노출될 수 있습니다.
액세스 토큰을 얻기 위해 암시적 승인 방식을 사용하는 인증 확인 프로세스를 User-Agent Flow라고도 하며, 이는 서버 협력 없이 모든 애플리케이션에 적합합니다(애플리케이션은 종종 다음과 같은 User Agent에 위치하므로). 따라서 이러한 유형의 애플리케이션은 모바일/데스크톱 클라이언트 프로그램, 브라우저 플러그인 등과 같은 일부 플랫폼에서는 클라이언트측 애플리케이션이라고도 하며, 스크립트 클라이언트 스크립트 언어를 기반으로 하는 애플리케이션이라고도 합니다. 일반적인 특징 중 하나는 앱이 앱 비밀 키를 제대로 유지할 수 없다는 것입니다. 인증 코드 모드를 채택하면 앱 비밀 키가 유출될 가능성이 있습니다. 프로세스 다이어그램은 다음과 같습니다.
+----------+
| 리소스 |
| 소유자 |
+---- ----+
~ --+
| +----(A)-- 및 리디렉션 URI --->| 사용자- | -(B) -- 사용자 인증 -->| 서버 |
| | | 조각 없음 | 고객 |
| | | 리소스 |
| (F) |
인증 코드 암시적 부여를 활성화하려면 Server.php의 104행에서 'allow_implicit'을 'true'로 수정해야 합니다.
2. access_token 받기
http://www.yii.com/oauth2/index.php?r=oauth2/authorize&response_type=token&client_id=testclient&state=xyz&redirect_uri=www.baidu .com
매개변수: response_type=token(필수, 고정 값)
client_id(필수)
redirect_uri 선택
범위 선택
> 사용하여 사용하여 사용하여 통해 전체를 통해 전체를 통해 out outmbmb outmb의 out out out out‐‐‐‐‐‐‐through 및 out of out ‐ ‐ ‐ ‐ ‐ 코드 대신에 토큰 100,000개. 왜냐하면 암시적 인증에는 인증 코드 획득이 필요하지 않기 때문입니다.
복귀:
성공:
사용자는 먼저 인증 버튼을 클릭해야 합니다.
성공! 인증 코드: www.baidu.com?#access_token=9f0c38b475e51ccd3
오류: 리디렉션_uri가 등록된 클라이언트 리디렉션_uri와 일치하지 않습니다.
{"error":"redirect_uri_mismatch","error_description":"제공된 리디렉션 URI가 없거나 일치하지 않습니다.","error_uri":"http://tools.ietf.org/html/rfc6749#section- 3.1.2"}
access_token은 리디렉션_uri의 프래그먼트에 존재합니다. 즉, '#' 기호 뒤에 클라이언트는 프래그먼트에 있는 access_token을 자체적으로 추출하여 저장해야 합니다. 개발자는 일부 사용자 에이전트가 HTTP "위치" HTTP 응답 헤더 필드에 조각 구성 요소를 포함하는 것을 지원하지 않는다는 점에 유의해야 합니다. 이러한 클라이언트는 클라이언트를 리디렉션하기 위해 3xx 리디렉션 응답 이외의 방법을 사용해야 합니다. 예를 들어 리디렉션 URI에 연결된 작업과 함께 "계속" 버튼이 포함된 HTML 페이지를 반환해야 합니다.
세 번째 인증 방법: Resource Owner Password Credentials(Resource Owner Password Credentials 권한)
Resource Owner Password Credentials 권한 유형은 리소스 소유자와 클라이언트 간의 신뢰에 적합합니다. 장치 운영 체제 또는 높은 권한의 애플리케이션과 같은 관련 상황. 인증 서버는 이 라이센스 유형을 활성화할 때 그리고 다른 프로세스를 사용할 수 없는 경우에만 특별한 주의를 기울여야 합니다.
이 권한 유형은 리소스 소유자의 자격 증명(사용자 이름 및 비밀번호, 일반적으로 대화형)을 얻을 수 있는 클라이언트에 적합합니다. 또한 저장된 자격 증명을 액세스 토큰으로 변환하여 HTTP 기본 또는 다이제스트 인증과 같은 직접 인증 체계를 사용하는 기존 클라이언트를 OAuth로 마이그레이션하는 데에도 사용됩니다.
+---------+
| 리소스 |
| 소유자 |
|
+----------+
v
리소스 소유자 +--------- ------+
|| 클라이언트 | 서버 | 그림 3에 표시된 흐름에는 다음 단계가 포함됩니다.
(A) 리소스 소유자는 클라이언트에 사용자 이름과 비밀번호를 제공합니다.
(B) 클라이언트는 리소스 소유자로부터 받은 자격 증명을 포함하여 인증 서버의 토큰 엔드포인트에서 액세스 토큰을 요청합니다. 요청할 때 클라이언트는 권한 부여 서버를 통해 인증합니다.
(C) 인증 서버는 클라이언트를 인증하고 리소스 소유자의 자격 증명을 확인한 후 유효한 경우 액세스 토큰을 발급합니다.
팁: 클라이언트는 액세스 토큰을 얻은 후에 자격 증명을 삭제해야 합니다.
oauth2-server-php는 다음과 같이 리소스 소유자 비밀번호 자격 증명을 구현합니다.
1. 먼저 Oauth2Controller 생성자에서 리소스 소유자 비밀번호 자격 증명 인증 방법에 대한 지원을 추가하고 다음 코드를 추가합니다.
$server->addGrantType(new OAuth2GrantTypeUserCredentials($storage));
2. access_token 가져오기:
컬 -u testclient:testpass www.yii.com/ oauth2/index.php?r=oauth2/token -d 'grant_type=password&username=rereadyou&password=rereadyou'
반환:
{"access_token":"66decd1b10891db5f8f63efe7cc352ce326895c6",
"expires_in": 3600 ,
"token_type":"bearer",
"scope":null,
"refresh_token":"b5fa0c24e786e37e7ce7d6e2f911805dc65a0d7c"}
팁: SQL은 Github의 oauth2-server-php에서 제공됩니다. 스키마 사용자 테이블에는 user_id 필드[12]가 없습니다. 이 필드(기본 키, auto_increment)를 직접 추가해야 합니다.
사용자 테이블은 소금을 추가하지 않고 sha1 다이제스트 방법을 사용하도록 설계되었습니다.
~ $ 사용자 반환 ['password'] == Sha1 ($ 비밀번호)
}
사용자 인증을 위해 이 기능을 다시 작성해야 합니다.
네 번째 인증 방법 : Client Credentials Grant(Client Credentials Grant)
클라이언트가 자신이 제어하는 것에 대한 접근을 요청하거나, 사전에 권한 부여 서버와 협상하는 경우( 클라이언트는 클라이언트 자격 증명(또는 기타 지원되는 인증 방법)만 사용하여 액세스 토큰을 요청할 수 있습니다.
클라이언트 자격 증명 권한 유형은 기밀 클라이언트만 사용해야 합니다.
|
|>--(A)- 클라이언트 인증 --->| 클라이언트 |
| --------------+
그림 4: 클라이언트 자격 증명 흐름
그림 4에 표시된 흐름에는 다음 단계가 포함됩니다.
(A) 클라이언트는 권한 부여 서버로 인증하고 토큰 엔드포인트와 통신하여 액세스 토큰을 요청합니다.
(B) 인증 서버는 클라이언트를 인증하고 유효한 경우 액세스 토큰을 발급합니다.
팁: 가장 간단한 인증 방법입니다.
인증권한은 클라이언트 인증을 사용하므로 별도의 인증요청은 필요하지 않습니다.
구현은 다음과 같습니다.
1. Oauth2Controller에서 클라이언트 자격 증명 인증 방법에 대한 지원을 추가합니다:
$server->addGrantType(new OAuth2GrantTypeClientCredentials($storage));
2. access_token 가져오기:
컬 -u testclient:testpass www.yii.com/oauth2/index.php?r=oauth2/token -d 'grant_type=client_credentials'
제출 매개변수: grant_type 필수. 값은 "client_credentials"로 설정되어야 합니다.
범위 선택사항
반환:
{"access_token": "f3c30def0d28c633e34921b65388eb0bbd9 d5ff9",
"expires_in":3600,
"token_type":"bearer",
"scope":null}
팁: 클라이언트는 자체 클라이언트 ID와 client_secret을 직접 사용하여 access_token을 얻습니다.
RFC6749 사양에서는 [10] clinet을 지정합니다. 인증을 위해 access_token을 얻을 때 crendentials 클라이언트 Refresh_token이 포함되지 않습니다.
그러나 oauth2-server-php는 OAuth2/GrantTypes/ClientCredentials.php 라인 33 [11]에서 제어 스위치를 제공합니다.
기본값 $includeRefreshToken = false; 동시에 새로고침_토큰.
3부: access_token 유형 설명
클라이언트는 데이터 리소스를 운영할 때(API를 통해) access_token을 서버에 제시해야 합니다. access_token 및 access_token 유형을 제시하는 방법은 다음 섹션에서 설명합니다.
IETF rfc 6749에는 Bearer 유형과 MAC 유형이라는 두 가지 access_token 유형이 설명되어 있습니다.
MAC 유형 access_token에 대해서는 OAuth2-Server-php가 아직 개발 중이므로 가장 일반적으로 사용되는 Bearer 유형 access_token만 아래에 설명합니다.
리소스 요청에서 Bearer access_token 리소스를 리소스 서버로 보내는 방법에는 세 가지가 있습니다[13]. 클라이언트는 요청당 토큰을 전송하기 위해 두 가지 이상의 방법을 사용할 수 없습니다.
a. HTTP/1.1 [RFC2617]에 정의된 "Authorization" 요청 헤더 필드에 액세스 토큰을 보낼 때 클라이언트는 "Bearer" 인증 체계를 사용하여 액세스 토큰을 전송합니다.
GET /resource HTTP/1.1
호스트: server.example.com
승인: Bearer mF_9.B5f-4.1JqM
클라이언트는 "Bearer" HTTP 인증 체계와 함께 "Authorization" 요청 헤더 필드를 사용하여 Bearer 토큰으로 인증 요청을 시작해야 합니다. 리소스 서버는 이 방법을 지원해야 합니다.
b. 양식으로 인코딩된 본문 매개변수
HTTP 요청 엔터티 본문에서 액세스 토큰을 보낼 때 클라이언트는 "access_token" 매개변수를 사용하여 요청 본문에 액세스 토큰을 추가합니다. 클라이언트는 다음 조건이 모두 충족되지 않으면 이 방법을 사용할 수 없습니다.
HTTP 요청의 엔터티 헤더에는 "application/x-www-form-urlencoded"로 설정된 "Content-Type" 헤더 필드가 포함되어 있습니다.
엔터티 본문은 HTML4.01 [W3C.REC-html401-19991224]에 정의된 "application/x-www-form-urlencoded" 콘텐츠 유형의 인코딩 요구 사항을 따릅니다.
HTTP 요청 엔터티 본문은 단일 부분입니다.
엔터티 본문에 인코딩된 콘텐츠는 전체가 ASCII [USASCII] 문자로 구성되어야 합니다.
HTTP 요청 방법은 요청 본문에 정의된 구문입니다. 특히 이는 "GET" 메소드를 사용할 수 없음을 의미합니다.
클라이언트는 전송 계층 보안을 사용하여 다음 HTTP 요청을 시작합니다.
POST /resource HTTP/1.1
호스트: server.example.com
콘텐츠 유형: application/ x -Www-Form-Urlencoded
Access_token = MF_9.B5F-4.1JQM
C. HTTP 요청 URI에서 액세스 토큰을 보낼 때 클라이언트는 "통합 리소스 라벨링 URI에 "Access_token" 매개변수를 사용합니다. "범용 구문" RFC3986은 액세스 토큰을 추가하기 위해 요청 URI의 쿼리 부분을 정의합니다.
예를 들어 클라이언트는 전송 계층 보안을 사용하여 다음 HTTP 요청을 시작합니다.
GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1
호스트: 서버. example.com
"Authorization" 요청 헤더 필드 또는 HTTP 요청 엔터티 본문에서 액세스 토큰을 전송할 수 없는 경우를 제외하고는 사용하면 안 됩니다.
위의 세 가지 access_token 사용 방법은 rfc6750 사양에서 제안되었습니다. 첫 번째 옵션을 사용하는 것이 좋습니다. Bearer 토큰을 사용하려면 access_token 전송의 보안을 보장하기 위해 TLS가 필요합니다.
반환:
{"access_token":"50540a7ead3a2 7cdb458b6c dc38df25f64da18f1",
"expires_in":3600,
" token_type":"bearer",
"scope":null}
여기에는 새로운 새로 고침 토큰이 없습니다. 새로 고침 토큰을 다시 얻으려면 OAuth2/에서 RefreshToken 클래스 __construct 메서드를 수정해야 합니다. GrantType/RefreshToken.php.'always_issue_new_refresh_token' => 새로운 Refresh_token 발급을 활성화하려면 true입니다.
팁: IETF rfc2649의 Refresh_token 섹션에 대한 부분 설명,
POST /token HTTP/1.1
호스트: server.example.com
인증: 기본 czZCaGRSa3F0MzpnWDFmQmF0M2JW
콘텐츠 유형: application/ x -www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
클라이언트의 client_id 및 client_secret을 제공해야 하며, grant_type 값은 Refresh_token이어야 합니다.
access_token의 유효기간 동안 Refresh_token을 사용하여 새로운 access_token으로 교환할 수 없습니다.
2. access_token 사용:
a. 클라이언트 앱은 access_token을 사용하여 리소스 정보를 얻습니다. "message":"your access token is valid."
이 부분은 단지 액세스 토큰의 유효성을 확인하기 위한 것입니다. 클라이언트 앱은 이 메서드를 직접 호출해서는 안 되지만, 서버는 리소스를 요청할 때 자체적으로 호출합니다. 판단에 따라 결과가 다르게 처리됩니다.
Oauth2 확장의 Server.php에서 access_token의 유효 기간을 수정할 수 있습니다.
3. 범위
범위에는 서버가 실행 가능한 특정 작업을 결정해야 합니다.
범위는 클라이언트가 수행할 수 있는 작업 권한을 결정하는 데 사용됩니다. 프로젝트의 작업 권한은 srbac에 의해 제어되며 당분간 Oauth2에서 처리되지 않습니다.
4. state
state는 클라이언트 앱이 첫 번째 단계에서 인증 코드를 얻을 때 OAuth2 서버에 전달되고 OAuth2 서버에서 반환되는 임의의 해시 매개 변수입니다. 상태 매개변수는 주로 사이트 간 요청 위조(Cross Site Request Forgery, CSRF)를 방지하는 데 사용됩니다. 관련 논의는 이 기사 끝에 있는 참고 자료 [7] 및 [8]을 참조하세요.
참고자료: