이전에 논의한 것처럼
OAuth 2.0 구조물은 다양한 유형의 웹 애플리케이션에 사용할 수 있는
다양한 승인 유형을 지원합니다
개발자로서
이러한 인증 유형 중 하나를
웹 애플리케이션 시나리오를 바탕으로 선택해야 합니다
그러기 위해서는 인증 유형 플로우의
차이가 무엇인지
이를 사용하려면 어떠한 시나리오를 적용해야 하는지
이해할 필요가 있습니다
그렇다면 이제 인증 유형을 개별적으로
다루어봅시다
장치 코드 인증 유형은 제외합니다
장치 코드 인증 유형을 제외하는 이유는
모두 다른 느낌이기 때문입니다
장치 코드 인증 유형은
Apple TV나 Android TV와 같은 장치에만 쓰이고
인증서에 브라우저나 키보드는
연관되어있지 않습니다
그리고 여러분이 이러한 시나리오를
여러분의 웹 애플리케이션에 대입하지 않을 것이라고 생각합니다
이러한 이유로
그 한 가지 유형을 제외하고
나머지 인증 유형을 다루어 보겠습니다
이들은 모두 OAuth 2.0 구조물 내에서 활용할 수 있습니다
가장 첫 번째 인증 유형은
인증 코드입니다
허가 코드 인증 유형 플로우를 활용할 때
기억해야 할
가장 중요한 규칙은
엔드 유저가 연관되어있거나
두 개의 다른 애플리케이션이 서로
교류하려고 할 때
이 플로우를 사용해야 한다는 점입니다
여기서 보면
리소스 소유자인 유저가 있고
클라이언트 애플리케이션이 있습니다
인증 서버와
리소스 서버도 있습니다
가장 첫 번째 단계에서는
리소스 소유자나
유저가 클라이언트 애플리케이션에게
리소스에 접근하고 싶다는 의사를 밝힐 것입니다
TweetAnalyzer의 시나리오에서
리소스는 리소스 서버 내에 있는
트윗들을 일컫습니다
그리고 Google Photos의 시나리오에서는
사진들이 리소스가 될 것입니다
여기서 제 유저는 클라이언트 애플리케이션에게
리소스 서버에서부터 리소스를 접속하게 해달라고 주장합니다
이 첫번째 단계 이후에, 클라이언트 애플리케이션이
엔드 유저에게 우리의 리소스 서버가
인증 서버의
허가를 받아야 한다고 합니다
왜냐하면
소비자가 접근하려는 리소스는
리소스 서버 내에 보관되어있으며
액세스 토큰와 소통하기 위해서는
인증 서버에게 먼저 소통해야 하기 때문입니다
액세스 토큰도 받아야 합니다
따라서 클라이언트 애플리케이션은
사용자에게 인증 서버와 협업하여
본인의 인증서를 제출해달라고 부탁할 것이며
허가를 달라고 하는 것입니다
제가 엔드 유저에게
두 번째 단계에서 언급하고 있는 부분은
이번 단계가 다 끝난다면
엔드 유저는
인증 서버 로그인 페이지로 이동하게 될 것이고
여기서 엔드 유저이자 리소스 소유자는
인증 서버에게
이것이 내 인증서이며
클라이언트가 리소스에 접근하게 해달라고 부탁해야 합니다
인증 서버가 인증서를 받고
리소스 소유자가 신원을 증명하면
인증 서버는 임시 인증 코드를 발급할 것입니다
이는 바로 접근 코드를 발급하는 것은 아닙니다
왜냐하면 내부적인
1, 2, 3, 4단계를 통해
인증 서버가 엔드 유저의 신원을
인증서를 통해
확인하고자 할 것이기 때문입니다
이 리소스 소유자 인증이 성공적으로 이루어졌다면
인증 서버는 클라이언트 애플리케이션에
인증 코드를 보낼 것입니다
이러한 인증 코드는
매우 짧은 기간동안 유효합니다
아마도 몇 초 정도겠죠
클라이언트 애플리케이션에 의해
승인코드를 받게 된다면
승인 서버에게
승인 코드를 발급받았다고
회신을 해야됩니다
이는 유저 인증이 성공적으로 이루어졌고
그가 본인의 리소스에 접근하는 것에 동의한다는 뜻입니다
이제 저는 액세스 토큰을 필요로 합니다
액세스 토큰을 제공하기 위해선
승인 서버가 클라이언트 인증서를 필요로 합니다
예를 들어, 클라이언트 ID, 클라이언트 기밀이 무엇인지
네 번째 단계에서 받은
인증 코드가 무엇인지와 같은 것들 말이죠
이러한 인증 코드, 클라이언트 ID
클라이언트 기밀 등 모든 것이 정확하다면
인증 서버가 클라이언트 애플리케이션으로
액세스 토큰을 발급할 것입니다
클라이언트 애플리케이션은 환호할 것입니다
액세스 토큰을 받게 되었으니
리소스 서버로 가서
리소스 소유자의 보안 처리된 리소스에
접속할 수 있을 것입니다
그리고 액세스 토큰과 함께
리소스 서버에게 토큰을 부여받았다는
회신을 보낼 것입니다
"저는 아무개 리소스 소유자의
이러한 특정 리소스에 접근하고 싶습니다"라고 말이죠
액세스 토큰이 적절한 것으로 확인되어
리소스 서버의 요구가 충족되면
그리고 동시에
클라이언트가 특정 리소스에 접근할만큼
충분한 스코프와 허가가 내려졌다면
리소스 서버는 클라이언트 애플리케이션이
요구했던 모든 리소스를
여덟번째 단계의 회신으로 돌려줄 것입니다
따라서 이것은 허가 코드 인증 유형의
완전한 플로우입니다
보시다시피 두 단계를 거친 인증이 요구됩니다
이것은 가장 첫 번째 단계이고
승인 서버는 리소스 소유자가
정확한지 아닌지를 판명할 것입니다
인증서를 통해서 말이죠
보안의 두 번째 단계는
인증 서버가 임시적으로 부여했던
임시 코드를 기다리고 있을 것입니다
클라이언트 애플리케이션으로부터 부여된
클라이언트 ID와 기밀도 함께 말이죠
만약 이 모든 단계가 충족됐다면
승인 서버가 액세스 토큰을 발급할 것입니다
여기서, 승인 서버가 성공적인 인증을 끝낸 후
회신하는 곳을
어떻게 알고 있는지에 대한 의문점을
가지게 되실 것입니다
이 모든 세부 사항은, 클라이언트 애플리케이션이
2단계와 3단계에서 볼 수 있듯이
인증 코드를 받으려고 할 때 알 수 있습니다
클라이언트 애플리케이션은 오직 클라이언트 ID만 보낼 것인데
클라이언트 기밀을 보내지 않는 이유는
클라이언트 기밀은 접근 토큰을 가지려고 하는
다음 단계에서 사용해야 하기 때문입니다
따라서 먼저, 클라이언트 ID가 보내질 것입니다
그리고 redirect_uri와 URI 세부사항
즉, 인증 서버가 성공적인 인증을 마친 후
리소스 소유자에게 안내해야 하는
정보입니다
그리고 스코프에서는, 리소스 소유자에게
동일한 스코프 세부사항이 보여지기 위해서
요구하고 있는 허가가 무엇인지에 대해
생각해보아야 합니다
클라이언트 애플리케이션이 이메일이나
사진 혹은 트윗에 접근하려고 할 때처럼 말이죠
이러한 스코프 세부 사항들이
엔드 유저에게 보여질 것이고
허락을 받으려고 노력할 것입니다
따라서, 스코프의 세부 사항을 보내는
부분이 매우 중요합니다
클라이언트는 상태값을 보내야 합니다
이 상태값은 CSRF 공격으로부터 보호하는
CSRF 토큰의 역할을 합니다
클라이언트 애플리케이션이 승인 서버에
보내는 상태값이 무엇이든지에 상관없이
클라이언트 애플리케이션에게
동일한 상태값이 회신되어야 합니다
요청 사항을 방해하는 사항이 없는 것을 확인하고
인증 서버가 보내는 것이
진실된 답변임을 확인하고자 하는 것입니다
따라서 상태값이 CSRF 토큰의 역할을 하는 것입니다
허가 코드 승인 유형 플로우 내에서 말죠
그리고 마지막으로, 답변 유형을 보내야 합니다
우리가 승인 코드를
2단계와 3단계의 일부분으로 제공받고 싶기에
우리는 답변 유형을 코드로 보내야 합니다
클라이언트 애플리케이션이 승인 코드를
스텝 파일 속에서 받으면
위의 단계에서 받았던 코드인 승인 코드를
보내주어야 합니다
그리고 코드와 더불어
본인의 신원을 증명하여야 합니다
따라서 클라이언트 애플리케이션이
클라이언트 ID와 함께
클라이언트 기밀도 공유하는 것이죠
이러한 클라이언트 ID와 기밀은
승인 서버를 통해 등록하는 과정에서
클라이언트 애플리케이션이
받게 될 것입니다
여러분들이 사용자 인증서보다
client_id, client_secret에 대해
확실히 알고 계셨으면 좋겠습니다
사용자 인증이 이미
위의 단계들을 실행했습니다
다음으로 거쳐야 할 단계는
"grant_type은 무엇인가?"입니다
이번에는, 우리가 보내야 하는 grant_type은
authorization_code입니다 즉
허가 코드 인증 유형을 받아야 한다는 뜻입니다
액세스 토큰을 부여해주십시오
이것이 우리가 grant_type의 도움을 통해서
소통하려고 하는 부분입니다
마지막으로 redirect_uri를 보내야 합니다
이 페이지에서는 인증 서버가
액세스 토큰과 함께
답변을 회신해야 합니다
여러분은 의문점이 생길 수 있습니다
"왜 인증 코드 유형 내에서
클라이언트가 두 번이나 요청을 하고 있나요?"
한 번은 인증 코드를 위한 것이고
두번째는 접근 코드를 위한 것입니다
이전에 언급했듯이
첫 번째 단계에서 인증 서버는
사용자가 인증서와 함께
직접 상호 작용했는지 확인합니다
세부 정보가 정확하고
리소스 소유자가 유효한 경우
클라이언트 애플리케이션이
임시 인증 코드를 받게 됩니다
두 번째 단계에서는
내 클라이언트는 자신의 신원을 증명해야 하기 때문에
이번에는 액세스 토큰을 얻기 위해
인증 코드와 함께
클라이언트 기밀
클라이언트 ID도 전달해야 합니다
그렇다면 서로 다른 두 단계가
더 나은 보안을 의미하는 이유는 무엇일까요?
클라이언트에서 승인 서버로 요청이
하나만 전송되는 경우
누구나 흐름을 해킹하기가 매우 쉽습니다
그렇기 때문에 두 단계를 거치면
우리는 훨씬 더 나은 흐름을 확보할 수 있는 것입니다
물론 인증 서버가
이 두 단계를 함께 결합하고
단일 단계로 토큰을 제공할 수는 없는지에 대한
질문이 있을 수도 있습니다
이에 대한 답은 이러한 종류의 동작을
지원하는 유형이 있다는 것입니다
이 유형을 암시적 유형이라고 부릅니다
하지만 이 유형은 사용하지 않는 것이 좋습니다
보안성이 낮고 더 이상 사용되지 않기 때문에
OAuth 2.1 버전에서는 제거되고 있습니다
하지만 인증 코드 유형 흐름과 암시적 유형 흐름의
차이점을 알 수 있도록
몇 초 안에 암시적 흐름이 무엇인지
보여 드리겠습니다
모든 것이 확실히 이해되셨길 바랍니다
다음 강의에서, 매우 명확하게 이해할 수 있도록
인증 코드 유형 흐름에 대한
간단한 데모를 제공하겠습니다
감사하고, 다음 강의에서 뵙겠습니다
수고하셨습니다