Facebook OAuth 2.0 "코드"및 "토큰"
https://developers.facebook.com/docs/authentication/에 설명 된대로 Facebook OAuth2 인증 흐름에서 "코드"와 "토큰"이 모두 필요한 이유는 무엇 입니까?
OAuth 대화 상자 참조 ( https://developers.facebook.com/docs/reference/dialogs/oauth/ )를 보면 사용자에 대한 정보를 가져 오는 데 토큰 만 사용하는 것 같습니다. response_type매개 변수를 token또는으로 code,token설정하면 처음에 토큰을받습니다.
토큰을 직접 가져 오는 대신 "코드"를 얻은 다음 코드를 사용하여 "토큰"을 가져와야하는 이유는 무엇입니까?
나는 OAuth가 작동하는 방식에 대해 기본적인 것을 오해하고 있다고 생각하지만 https://graph.facebook.com/oauth/access_token대화로 처음 토큰을 받으면 요청을 완전히 피하는 것 같습니다 .
인증 코드와 액세스 토큰을 구분하는 간단한 예를 들어 보겠습니다.
사용자는 Highjack이라는 새로운 Facebook 앱을 사용하고 싶어합니다. 따라서 응용 프로그램과 Highjack 앱을 클릭합니다. Facebook 계정에 로그인하도록 요청합니다. 완료되면 Facebook에서 인증 코드를 생성합니다.
이 코드는 자체 FB 클라이언트 ID, FB 비밀 및 액세스 토큰을 얻기 위해 인증 코드를 사용하는 Highjack 서버로 전달됩니다.
위의 예에서 인증 코드는 사용자가 유효한 FB 사용자임을 확인합니다. 그러나 두 번째 단계에서는 "FB 사용자로서 특정 리소스에 대해 Highjack 앱에 대한 액세스 권한을 부여합니다"라고 말합니다.
Highjack 앱이 암시 적 승인 (예 : 직접 액세스 토큰)을 원하면 액세스 토큰이 브라우저와 교환되기 때문에 사용자에게도 표시됩니다. 즉, 이제 액세스 토큰을 사용하여 Highjack을 대신하여 모든 Facebook API를 호출 할 수 있습니다. (액세스 토큰을 사용하여 개인 정보를 얻을 수 있지만 Facebook은 API를 호출하는 사람을 알 수 없습니다.)
Facebook으로 인증하는 2 개의 당사자 (귀하와 하이 잭)가 있기 때문에이 두 가지 방식이 있습니다.
Salesforce 문서 에서 뻔뻔하게 빌 렸습니다 .
인증 코드
인증 코드는 인증 서버에 의해 생성되고 브라우저를 통해 클라이언트 애플리케이션에 전달되는 사용자의 액세스 권한을 나타내는 단기 토큰 입니다. 클라이언트 애플리케이션은 액세스 토큰 및 선택적으로 새로 고침 토큰을 얻기 위해 권한 부여 서버에 권한 부여 코드를 보냅니다.
액세스 토큰 액세스 토큰은 클라이언트가 최종 사용자를 대신하여 인증 된 요청을 만드는 데 사용됩니다. 그것은이 긴 수명 일반적으로 몇 분 또는 몇 시간의 순서에 인증 코드보다 더합니다. 액세스 토큰이 만료되면 사용 시도가 실패하고 새로 고침 토큰을 통해 새 액세스 토큰을 얻어야합니다.
보내는 사람 의 OAuth 2.0 사양 :
인증 코드는 클라이언트를 인증하는 기능, 액세스 토큰을 리소스 소유자의 사용자 에이전트를 통과하지 않고 클라이언트에 직접 전송하는 등 몇 가지 중요한 보안 이점을 제공하여 리소스 소유자를 포함한 다른 사용자에게 잠재적으로 노출 할 수 있습니다. .
따라서 기본적으로 주된 이유는 액세스 토큰을받는 액터의 수를 제한하는 것입니다.
"토큰"응답은 주로 브라우저에있는 클라이언트 (예 : JavaScript 클라이언트)를위한 것입니다.
Authorization Code OAuth type 의 흐름 을 살펴보면 예, 계리적인 두 단계가 있습니다.
1. <user_session_id, client_id> => authorization_code
2. <client_id, redirect_uri, authorization_code, client_secret> => access_token, refresh_token
1 단계 : 사용자가 OAuth 서버에 "내 리소스에 액세스하기 위해이 cliet (client_id)를 인증하고 싶습니다. 여기에 내 인증 (user_session_id 또는 기타)이 있습니다."라고 말합니다.
2 단계에서 클라이언트 (client_id)는 OAuth 서버에 "사용자에게 권한 부여 (authorization_code)가 있습니다. 나중에 액세스 할 수 있도록 액세스 토큰을주세요. 이것이 제 인증 (client_id & client_secret)입니다."라고 말합니다.
2 단계를 생략하면 클라이언트 인증이 보장되지 않습니다. 모든 클라이언트는 다른 client_id를 사용하여 step1을 호출하고 자체 대신 해당 client_id에 대한 액세스 토큰을 얻을 수 있습니다. 그래서 2 단계가 필요합니다.
1 단계와 2 단계를 결합하고 싶다면 다음과 같이 할 수 있습니다.
<client_id, redirect_uri, client_secret> => access_token, refresh_token
Open Api 플랫폼에서이 접근 방식을 사용하며 아직 보안 문제를 발견하지 못했습니다.
BTW, 실제로 암시 적 허용 유형 이 존재합니다.
<client_id, redirect_uri> => access_token, refresh_token
일반적으로 서버 백엔드가없는 클라이언트 전용 애플리케이션에 적용됩니다. 이 경우 OAuth 서버는 리디렉션 URI가 해당 클라이언트에 속하는지 확인해야합니다 (예 : register redirect_uri와 동일).
혼동은 클라이언트 앱이 아닌 사용자 가 인증 서버 (예 : facebook) 에 대해 인증 하기 때문에 발생했습니다 . 클라이언트 앱 (https 사용)과 사용자 에이전트 (브라우저)를 보호하는 것은 훨씬 간단합니다.
다음은 IETF-oauth ( http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-08#section-3.4 ) 의 원래 공식입니다 .
3.4. 인증 코드
인증 코드는 성공적인 최종 사용자 인증 프로세스의 중간 결과를 나타내며 클라이언트가 액세스를 얻고 토큰을 새로 고치는 데 사용됩니다. 인증 코드는 두 가지 목적으로 토큰 대신 클라이언트의 리디렉션 URI로 전송됩니다.
브라우저 기반 흐름은 URI 쿼리 매개 변수 (HTTP 리퍼러), 브라우저 캐시 또는 로그 파일 항목을 통해 잠재적 인 공격자에게 프로토콜 매개 변수를 노출하며 재생할 수 있습니다. 이러한 위협을 줄이기 위해 토큰 대신 단기 인증 코드가 전달되고 클라이언트와 인증 서버 간의보다 안전한 직접 연결을 통해 토큰으로 교환됩니다.
간접 인증 요청의 컨텍스트에서보다 클라이언트와 인증 서버 간의 직접 요청 중에 클라이언트를 인증하는 것이 훨씬 간단합니다. 후자는 디지털 서명이 필요합니다.
답변) 추가 보안을 위해 코드와 토큰이 모두 필요 / 원합니다.
Nate Barbettini에 따르면 인증 코드는 전면 채널에서 사용할 수 있고 (보안 수준이 낮음) 액세스 토큰은 후면 채널에서 사용할 수 있기 때문에 (보안 수준이 높음) 액세스 토큰에 대한 인증 코드를 교환하는 추가 단계를 원합니다. .
따라서 보안상의 이점은 액세스 토큰이 브라우저에 노출되지 않아 브라우저에서 가로 채거나 잡을 수 없다는 것입니다. 우리는 백 채널을 통해 통신하는 웹 서버를 더 신뢰합니다. 비밀 인 액세스 토큰은 웹 서버에 남아있을 수 있으며 브라우저 (즉, 프런트 채널)에 노출되지 않습니다.
자세한 내용은이 환상적인 비디오를 시청하십시오.
OAuth 2.0 및 OpenID Connect (일반 영어) https://youtu.be/996OiexHze0?t=26m30s (시작 26 분)
기본적으로 Lix 답변 의 확장으로 액세스 코드 경로를 사용하면 리소스 소유자 (예 : Facebook 사용자)가 오프라인 클라이언트에 대한 권한을 취소하지 않고 로그 오프 (예 : 로그 오프)하여 사용자 에이전트 (예 : 브라우저)에 대한 권한을 취소 할 수 있습니다. 너의 어플리케이션). 이것이 중요하지 않은 경우 액세스 코드 경로를 사용할 필요가 없습니다.
또한 서버에 제공된 토큰이 실제로 사용자 에이전트 (또는 중간자)가 아닌 리소스 소유자 (예 : Facebook 사용자)에 등록되었는지 확인하기 위해 액세스 코드가 제공됩니다.
이것은 암시 적 대 권한 부여 코드 부여 흐름을 선택하는 질문과 유사합니다. 사실, 여기에 반대 시점처럼 보이는 것은?! .
또한, 같은 드류 한 ,
액세스 토큰이 만료되면 사용 시도가 실패하고 새로 고침 토큰을 통해 새 액세스 토큰을 얻어야합니다.
또 다른 부분은 새로 고침 토큰이지만 FB 문서에서 너무 잘 설명되지 않습니다. 내가 맞다면 암시 적 부여 (직접 토큰)는 정말 짧아야하지만 시행 될 예정이며 FB.js는 많은 것을 숨기는 것 같습니다 (이것에 대해 자세히 살펴 보지 않았습니다). .
내가 맞다 code%20token면 사용자 에이전트가 토큰을 가질 수 있고 서버가 단일 요청으로 토큰 교환 프로세스를 시작할 수 있도록 허용하는 최적화입니다 (네트워크 IO를 통한 모든 것은 비용이 많이 드는 것으로 간주되므로 특히 사용자 에이전트에게) .
이론적으로
- 액세스 토큰 은 사용자가 인증되었는지 여부를 알 수 없지만 인증 코드는 확인합니다.
- API에 대한 액세스 권한을 얻기 위해 인증 코드를 사용 해서는 안되지만 액세스 토큰은 사용해야합니다.
백엔드가 없거나 최소 인 단일 페이지 애플리케이션 또는 모바일 애플리케이션이있는 경우 애플리케이션은 프런트 엔드에서 직접 사용자의 FB 데이터에 액세스하려고 할 수 있습니다. 따라서 액세스 토큰이 제공됩니다.
다른 경우에는 사용자가 Facebook, Google 등과 같은 외부 인증 서비스 제공 업체를 사용하여 앱에 등록 / 로그인하도록 할 수 있습니다.이 경우 프런트 엔드는 액세스 토큰을 얻는 데 사용할 수있는 인증 코드를 백엔드로 보냅니다. 서버 측의 Facebook에서. 이제 서버에서 사용자의 FB 데이터에 액세스 할 수 있습니다.
It’s because the access token is given to an AUTHENTICATED client (third-party app) using a shared secret that only FB and the client knows. The only way that the user could directly request the access token is by knowing the shared secret, which would make the secret public and could lead to a man-in-the-middle attack. Further, while FB can guarantee a secure connection to the user, FB can’t guarantee the handoff of the token to the client is secure. However, FB (and OAuth2) does require a secure connection between the client and FB. The access token is tied to the client public ID (usually hashed), which means only the original client application can use it to request the token because the secret is sent along with the authorization code to get the access token.
In OAuth 2.0 with facebook, the overall concept is simple as follows.
Step 1. Obtain "Authorization Code" by a GET request
request URI: https://www.facebook.com/dialog/oauth
Params:
response_type=code
client_id={add your "App id" got by registering app}
redirect_uri={add redirect uri defined at the registration of app}
scope={add the scope needed in your app}
Headers: None
Step 2. Obtain the "Access Token" by sending the authorization code as a POST request
URI: https://graph.facebook.com/oauth/access_token
Params:
grant_type=authorization_code
client_id=<add your "App id" got by registering app>
redirect_uri=<add redirect uri defined at the registration of app>
code=<obtained authorization code from previous step>
Headers:
Authorization:Basic encode <App Id:App Secret> with base64
Content-Type:application/json
Step 3. Use the access token got from above step and retrieve user resources
You recieve a token when the user logs in. But you might want to change the token when you are performing other actions. EG posting as your app/page or posting as a user with offline_access.
참고URL : https://stackoverflow.com/questions/8666316/facebook-oauth-2-0-code-and-token
'IT박스' 카테고리의 다른 글
| Style과 ControlTemplate의 차이점 (0) | 2020.12.01 |
|---|---|
| Assets 폴더의 파일에 Android 경로 문자열을 가져 오는 방법은 무엇입니까? (0) | 2020.12.01 |
| Array.empty의 반대 방법은 무엇입니까? (0) | 2020.12.01 |
| Git 되돌리기를 사용하는 방법 (0) | 2020.12.01 |
| 배포 된 Kubernetes 서비스 용 YAML을 받으시겠습니까? (0) | 2020.12.01 |