OAuth2 흐름을 이해하려고 시도했습니다.

Question

그래서 OAuth2를 사용하여 Provider를 구현하고 있습니다.

클라이언트가 client_id 및 client_secret에 적용되는 부분을 얻습니다. 이것은 공급자에게 고유하게 식별됩니다.

이제 SSL을 통해 인증 토큰이 필요한 이유가 무엇입니까? 그런 다음 권한 부여 코드가 필요한 이유는 무엇입니까?

왜 새로 고침 토큰입니까?

왜 우리는 client_id 및 client_secret을 사용할 수 있습니까? 최종 사용자의 권한에 따라 보호되는 리소스에 대해서는 예외적 인 권한이 필요합니다. 그만큼 의미가 있습니다. 하지만 왜 인증 토큰 AND 코드입니까?

마지막으로 최종 사용자가 보호하지 않는 리소스에이 모든 것이 필요합니까?

그래서, 나는 나를 이해하는 데 도움이되는 5 개 가지 질문을 추측 :

1. 왜 인증 토큰을?
2. 인증 코드가 필요한 이유는 무엇입니까?
3. 왜 새로 고침 토큰이 필요합니까?
4. 보호되지 않은 리소스에 클라이언트 자격 증명을 사용하는 것만으로도됩니까?
5. 왜 모두 인증 토큰 및 코드? (나는 이것이 1과 2 모두에 의해 대답 될지도 모른다).

Answer 1

네크로 포스 팅에 대해 사과드립니다. 나중에 참조 할 수 있도록 유용하게 활용되기를 바랍니다.

처음에는 Authorization Code 및 Access Token이라고합니다.

1. Access Token
   는 자원
2. Authorization Code에 액세스 할 수있는 권한을 나타내는 문자열입니다 리소스 소유자가 클라이언트에 제공하는 권한을 나타냅니다. 대부분의 경우 리소스 소유자는 서버에서 일부 리소스를 소유 한 최종 사용자 인 입니다. 클라이언트 은 이러한 리소스에 액세스하기를 원하므로 사용자에게 의 권한이 필요합니다.
3. Refresh Token은 만료 갱신에 사용됩니다. Access Tokens. 우스 알리는 액세스 토큰의 수명이 몇 분이며, 새로 고침은 몇 개월/년 후에 만료됩니다. 당신은 액세스 것들을 사용합니다; 그들이 오래되면 새로 고침 토큰을 사용하여 새 액세스 토큰을 얻습니다. OAuth1에는 몇 개월 동안 지속 된 토큰 유형 하나만있었습니다. 짧은 수명의 토큰이 프로토콜 보안을 향상시키기 위해 도입되었습니다.
4. 나는 내가 싫어했다고 생각하지 않습니다. 리소스가 보호되지 않으면 OAuth를 사용하지 마십시오! 어쨌든 당신이 클라이언트 이 리소스 소유자 (here an example이라고 생각 할 때 사용할 Client Credential Grant있다.
5. 그들은 다른이며, 또한 두 개의 서로 다른 채널을 통해 전송 될 수있다 (하지만 여전히 피난처 '1과 2 참조 다른 채널의 사용을 발견하지 못함).

간단히 말해 클라이언트에 인증 코드가있는 경우 인증 서버 (AS)에게 "ehi, 리소스 소유자가 리소스에 액세스 할 수 있다고했습니다!"라고 말합니다. AS는 클라이언트에게 액세스 토큰을 제공합니다. 이제 그는 토큰을 가지고 있으므로 클라이언트는 리소스 서버로 이동합니다. "권한 부여 서버는 리소스에 액세스하여 내 토큰을 볼 수 있다고 말했고"리소스를 얻습니다. 4 개 흐름이 있다는 것을

가

참고, 모든 사람은 다른 인증 그랜트의 종류와 그 중 하나만 사용 권한 부여 코드입니다. 그것은 모두 asbout 단어입니다. 메커니즘에 대해서는 먼저 this (a little obsolete) introduction을 읽고 다시 읽는 것보다 RFC 6749을 염두에 두십시오.

이제는 더 명확한 아이디어가 있기를 바랍니다.