oauth-2.0/

[utterances-bot]

OAuth 2.0 개념과 동작원리

https://hudi.blog/oauth-2.0/

[HJ-Rich]

👍👍👍

[finalboogi]

오오 OAuth2.0 설명하는 다른 문서들은 대부분 좀 뭔가 뭉뚱그려 얘기해서 뭐가 뭔지 제대로 파악하기 힘들었는데, 여기에는 잘 쓰여져 있군요 ㅎㅎ

[luckylooky2]

github에 로그인하려는데 생각지도 못한 OAuth가 나오는게 재밌네요!
아주 설명을 잘하시네요! 글 잘 읽었습니다.

[ko-yerin]

정리가 잘되있어서 퍼갑니다!!!

[TaeHyeongKwon]

조금 이해가 안되는데 8번과정에서 인증서버에서 발급받은 엑세스 토큰을 DB에 저장했는데, 12번 과정에서 결국 인증서버의 엑세스 토큰을 검증해서 자사의 리소스를 제공한다는 말이 조금 이해가 안되네요. 인증서버의 토큰을 자사에서 어떻게 검증처리 할 수 있는 건가요? 자사서버는 검증할 인증서버의secretkey같은걸 알지 못할거라는 생각이 드는데

[met-flo]

@TaeHyeongKwon 님,
인증 서버랑 리소스 서버는 같은 서비스 제공자 입니다.
예를 들면 구글이 로그인을 하면 획득한 토큰정보로 지메일도 접근하고 구글드라이브도 사용할 수 있죠.
여기서는 CLIENT 에서 사용자의 구글계정에 대한 특정권한을 접근 가능한 토큰을 획득하게 됩니다. 획득한 토큰으로 사용자의 ID 나 생일 등의 정보를 조회할 수 있죠.

[TaeHyeongKwon]

@met-flo 님,
이해가 잘 안되네요.
만약 A라는 사이트에서 kakao로그인을 진행했다고 한다면, kakao 인증 서버에서 토큰을 주고, 그 토큰으로 사용자의 정보를 얻기 위한 요청을 한번 더 kakao서버로 보내고 거기서 받은 사용자 정보를 사용할 수 있겠죠. 실질적인 Token의 secretkey를 알지 못하면 해당 토큰에서 정보를 꺼낼 수 없지 않나요?

A사이트에 게시물 리스트를 요청하는 API로 게시글리스트 리소스를 요청하고, 해당 리소스를 제공하는 서버는 A사이트의 서버가 되지 kakao서버가 될 수는 없다고 생각이 들어서요.

10번 과정부터 13번 과정까지는 A사이트의 서버와 통신을 하게 될 텐데 갑자기 DB에 저장한 kakao 토큰으로 검증을 하게 되니까 그게 가능한 일인지 의문이 들어요.

리소스 서버와 인증 서버가 같다는게 이해가 잘 안되네요.

[ctp102]

@TaeHyeongKwon님
인증 서버가 제공한 액세스 토큰으로 리소스 서버에 제한된 리소스를 요청을 하게 되면 토큰을 리턴하는게 아니라 요청한 리소스들을 map 형식으로 리턴해줍니다. 따라서 secretkey랑은 전혀 관련이 없습니다.

[TaeHyeongKwon]

@ctp102 님
제한된 리소스를 요청한다는 것 자체가 해당 리소스에 요청에 대한 토큰을 검증해야하는 과정인데 secretkey랑은 전혀 관련이 없나요?

제가 위에 들었던 예시에서
"만약 A라는 사이트에서 kakao로그인을 진행했다고 한다면, kakao 인증 서버에서 토큰을 주고, 그 토큰으로 사용자의 정보를 얻기 위한 요청을 한번 더 kakao서버로 보내고 거기서 받은 사용자 정보를 사용할 수 있겠죠. "
에 처음 인증서버에서 얻은 토큰으로 사용자 정보를 요청하는 부분이 11번 과정이 되는거고, 해당 요청을 받는 kakao서버가 리소스 서버가 된다는 말씀이시죠?

10~13번까지의 매커니즘에 대한 설명이 위에서
"Resource Owner가 Resource Server의 리소스가 필요한 기능을 Client에 요청한다. Client는 위 과정에서 발급받고 저장해둔 Resource Owner의 Access Token을 사용하여 제한된 리소스에 접근하고, Resource Owner에게 자사의 서비스를 제공한다." 라고 했는데 A사 입장에서는 제한된 리소스에 접근하는 과정 자체를 토큰 검증의 로직으로 사용해서 해당 리소스에 접근이 가능하면 해당 토큰이 Resource Server가 가지고 있는 검증로직 내의 secretkey와 비교되서 된 거고 리소스 접근 결과에 따라서 자사의 서비스를 제공할지 말지를 정하는거죠?

제가 12번과 13번의 리소스를 한번에 뭉쳐서 같은 리소스라 생각하고 있었네요. 같은 리소스라 생각하니 리소스 서버를 A사의 서버라고 생각하게 되구요. 12번은 소셜 로그인 서버에서 제공하는 리소스를 클라이언트단에 보내주고, 해당 클라이언트는 그 리소스를 파악하고나서 자사의 다른 리소스를 보내준다고 생각하는데 맞는거 같네요.

[ctp102]

@TaeHyeongKwon
'제한된 리소스를 요청한다는 것 자체가 해당 리소스에 요청에 대한 토큰을 검증해야하는 과정인데 secretkey랑은 전혀 관련이 없나요?'
--> 토큰을 검증하는 건 Resource Server에서 하지 않을까요? Authorization Server(인증 서버)에서 액세스 토큰을 발행하지만 Resource를 Resource Server에게 요청하는거니깐 Resource Server에서 검증을 진행할 것 같습니다. 제 예상이지만 Resource Server에서 Authorization Server에 call하는 방식으로 검증을 처리하지 않을까 싶습니다. secretKey가 인증서버 쪽에 있으니까요.

'제가 위에 들었던 예시에서
"만약 A라는 사이트에서 kakao로그인을 진행했다고 한다면, kakao 인증 서버에서 토큰을 주고, 그 토큰으로 사용자의 정보를 얻기 위한 요청을 한번 더 kakao서버로 보내고 거기서 받은 사용자 정보를 사용할 수 있겠죠. "
에 처음 인증서버에서 얻은 토큰으로 사용자 정보를 요청하는 부분이 11번 과정이 되는거고, 해당 요청을 받는 kakao서버가 리소스 서버가 된다는 말씀이시죠?'
--> 네 맞습니다. 태형님께서 말씀하시는 kakao 서버는 '리소스 서버'입니다.

'10~13번까지의 매커니즘에 대한 설명이 위에서
"Resource Owner가 Resource Server의 리소스가 필요한 기능을 Client에 요청한다. Client는 위 과정에서 발급받고 저장해둔 Resource Owner의 Access Token을 사용하여 제한된 리소스에 접근하고, Resource Owner에게 자사의 서비스를 제공한다." 라고 했는데 A사 입장에서는 제한된 리소스에 접근하는 과정 자체를 토큰 검증의 로직으로 사용해서 해당 리소스에 접근이 가능하면 해당 토큰이 Resource Server가 가지고 있는 검증로직 내의 secretkey와 비교되서 된 거고 리소스 접근 결과에 따라서 자사의 서비스를 제공할지 말지를 정하는거죠?

제가 12번과 13번의 리소스를 한번에 뭉쳐서 같은 리소스라 생각하고 있었네요. 같은 리소스라 생각하니 리소스 서버를 A사의 서버라고 생각하게 되구요. 12번은 소셜 로그인 서버에서 제공하는 리소스를 클라이언트단에 보내주고, 해당 클라이언트는 그 리소스를 파악하고나서 자사의 다른 리소스를 보내준다고 생각하는데 맞는거 같네요.'
--> 12번은 Resource Server에서 Client에게 요청한 리소스에 대한 응답을 내려주고 13번은 Client가 Resource Server로부터 응답받은 리소스를 입맞에 맞게 가공해서 사용자(Resource Owner)에 json으로 내려주는 것을 의미합니다.

[ctp102]

@TaeHyeongKwon 저는 저렇게 이해하고 사용해왔는데 혹시나 잘못된 부분이 있으면 말씀해주세용

[geunheejung]

좋은 글 감사합니다!

[met-flo]

@TaeHyeongKwon 언제 적었는지 기억도 안나는 코멘트였는데요. 지금 다시보니 @ctp102 님께서 자세히 답변을 해 주셔서 이미 이해하신 것 같네요 ^^

[P0cas]

늦었지만 .. @TaeHyeongKwon 토큰 검증 방법도 여러 가지가 있는데, 윗 분이 설명 해드린 것처럼 리소스 서버가 인증 서버의 Introspection 엔드포인트에 토큰을 전달해서 인증 서버가 해당 토큰의 상태를 반환하도록 해서 검증하는 방법도 있습니당

[Programming-Seungwan]

이전에 passport 모듈을 공부할 때에는 참으로 애매했던 개념들이 너무 잘 이해가 되었습니다! 좋은 포스팅 잘 보고 갑니다 :)

[f2koi]

글이 정리가 잘 되어 있어서 정말 잘 읽히네요 좋은 글 감사합니다!

[wndudrla1011]

좋은 글 감사합니다^^

[dlwnsgus07]

일하다가 공부겸 봤는데 또 당신입니까 후디...

[HuttTheJAVA]

잘 읽고갑니다!

[Zerotay]

이해가 잘 되었습니다 감사합니다.
개인적인 추측으로 access token을 리소스 오너에게 주지 않는 이유를 덧대봅니다.
access token은 리소스 서버 인가에 사용되는데 이것에 엔드 유저가 접근할 수 있는 것 자체가 공격 표면을 넓히는 일이라 위험하지 않나 생각합니다.
oauth는 리소스 서버 입장에서도 클라이언트만이 해당 토큰을 가지고 있다는 것을 보장되는 방식이기에 리소스 서버 입장에서도 소스ip 검증이 한결 수월할 것입니다.
https를 사용하는 이상 redirect uri로 access token이 전달되는 것 자체가 탈취를 야기하지는 않을 거라 생각합니다.