OAuth 인증 코드와 암시 적 워크 플로의 차이점은 무엇입니까?

OAuth 인증 코드와 암시 적 워크 플로의 차이점은 무엇입니까? 각각을 언제 사용해야합니까?

---

OAuth 2.0에는 여러 워크 플로우가 있습니다. 두 가지에 대해 몇 가지 질문이 있습니다.

1. 인증 코드 흐름 -사용자가 클라이언트 앱에서 로그인하면 인증 서버가 인증 코드를 앱에 반환합니다. 그런 다음 앱은 인증 코드를 액세스 토큰으로 교환합니다.
2. 암시 적 부여 흐름 -사용자가 클라이언트 앱에서 로그인하면 권한 부여 서버가 클라이언트 앱에 직접 액세스 토큰을 발급합니다.

보안 측면에서 두 방법의 차이점은 무엇입니까? 어느 것이 더 안전하고 왜?

서버가 직접 액세스 토큰을 발행 할 수있을 때 하나의 작업 흐름에 추가 단계 (토큰에 대한 교환 인증 코드)가 추가되는 이유는 알 수 없습니다.

다른 웹 사이트에서는 클라이언트 앱이 자격 증명을 안전하게 유지할 수있을 때 인증 코드 흐름이 사용된다고 말합니다. 왜?

---

는 access_token보호 된 자원 (API를) 호출 할 필요가 것입니다. 인증 코드 흐름에는 두 가지 단계가 있습니다.

1. 사용자는를 인증하고 codeAPI 소비자 ( "클라이언트"라고 함)에게 반환해야합니다 .
2. API를 (일반적으로 웹 서버)가이 교류의 "클라이언트" code에 대한 # 1에서 얻어진 access_token, 자신을 인증하는 client_id과client_secret
3. 그런 다음로 API를 호출 할 수 있습니다 access_token.

따라서 이중 확인이 있습니다. API를 통해 노출 된 리소스를 소유 한 사용자와 API를 사용하는 클라이언트 (예 : 웹앱). 둘 다 액세스 권한이 부여되었는지 확인합니다. 여기서 OAuth의 "권한 부여"특성에 주목하십시오. 사용자는 자신의 리소스에 대한 액세스 권한 ( code인증 후 반환을 통해 )을 앱에 부여하고 앱을 가져 access_token오고 사용자를 대신하여 호출합니다.

암시 적 흐름에서, 단계 2는 생략된다. 따라서 사용자 인증 후에 access_token는 리소스에 액세스하는 데 사용할 수있는가 직접 반환됩니다. API는 누가 해당 API를 호출하는지 모릅니다. access_token이전 예제에서는 웹 앱만 사용할 수 있지만 캔을 가진 사람은 누구나 사용할 수 있습니다.

암시 적 흐름은 일반적으로 저장 client id하고 client secret권장하지 않는 시나리오에서 사용됩니다 (예를 들어, 많은 사람들이 사용하지만 장치). 그것이 면책 조항의 의미입니다. 사람들은 클라이언트 코드에 액세스 할 수 있으므로 자격 증명을 얻어 리소스 클라이언트가 될 수 있습니다. 암시 적 흐름에서 모든 데이터는 일시적이며 앱에는 아무것도 저장되지 않습니다.

---

위의 답변에서 명확하지 않다고 생각되는 것을 여기에 추가하겠습니다.

• Authorization-Code-Flow를 사용하면 최종 액세스 토큰 이 브라우저 / 앱을 사용하여 머신에 절대 도달하지 않으며 저장되지 않습니다 . 임시 인증 코드는 브라우저 / 앱이있는 컴퓨터에 제공되며 서버로 전송됩니다. 그런 다음 서버는 전체 액세스 토큰으로 교환하고 API 등에 액세스 할 수 있습니다. 브라우저가있는 사용자는 토큰이있는 서버를 통해서만 API에 액세스 할 수 있습니다.
• 암시 적 흐름에는 두 당사자 만 참여할 수 있으며 최종 액세스 토큰은 브라우저 / 앱과 함께 클라이언트에 저장됩니다. 이 브라우저 / 앱이 손상되면 인증 토큰이 위험 할 수 있습니다.

TL; DR은 당신이 보류 토큰에 사용자의 컴퓨터를 신뢰하지 않는 경우 암시 적 흐름을 사용하지 않는하지만 당신은 어떻게 당신의 자신의 서버를 신뢰합니다.

---

둘의 차이점은 다음과 같습니다.

1. 암시 적 흐름에서 토큰은 "#"기호가있는 리디렉션 URL을 통해 직접 반환되며 이는 자체 서버 측이없는 자바 스크립트 클라이언트 또는 모바일 응용 프로그램에서 주로 사용되며 클라이언트는 일부 구현에서 비밀을 제공 할 필요가 없습니다. .

2. 인증 코드 흐름에서 코드는 "?"와 함께 반환됩니다. 서버 측에서 읽을 수 있도록 서버 측은 권한 부여 서버에서 토큰을 json 객체로 가져 오기 위해 이번에 토큰 URL에 클라이언트 비밀을 제공해야합니다. 이를 처리하고 자신의 시스템에 자신의 프로필과 함께 사용자 토큰을 저장할 수있는 응용 프로그램 서버가있는 경우에 사용되며 대부분 일반 모바일 응용 프로그램에 사용됩니다.

따라서 클라이언트 응용 프로그램의 특성에 따라 달라집니다. 클라이언트에 대한 비밀을 요청하고 매우 안전한 연결을 통해 권한 부여 서버와 클라이언트 응용 프로그램간에 토큰을 보낼 수있는 하나 이상의 안전한 "권한 부여 코드"가 있습니다. 일부 클라이언트가 "권한 부여 코드"만 사용하도록 제한하고 암시 적 허용 안 함

---

암시 적 부여는 인증 코드 부여와 유사하며 두 가지 차이점이 있습니다.

모든 응용 프로그램 코드와 저장소에 쉽게 액세스 할 수 있기 때문에 클라이언트를 비밀로 유지할 수없는 사용자 에이전트 기반 클라이언트 (예 : 단일 페이지 웹 앱)에 사용됩니다.

둘째, 인증 서버가 액세스 토큰과 교환 된 인증 코드를 반환하는 대신 인증 서버는 액세스 토큰을 반환합니다.

자세한 내용은 여기 http://oauth2.thephpleague.com/authorization-server/which-grant/를 참조하십시오

---

암시 적 흐름

장점

• 가장 간단한 구현

단점

• 브라우저에 보이는 액세스 토큰
• 액세스 토큰의 출처를 결정할 수 없습니다
• 액세스 토큰은 만료 될 수 없습니다 (Google 정책에 따라)

---

인증 코드 흐름

장점

• 가장 안전한
• 공유 암호를 알고있는 경우에만 액세스 토큰 및 새로 고침 토큰을 만들 수 있습니다
• 새로운 보안 및 UX 기능을 사용할 수있게되면 향상 될 수 있습니다

단점

• 여러 인증 엔드 포인트를 구현해야합니다.

인용 : https://developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows

---

위의 답변에서 배운 요점을 요약하고 내 자신의 이해를 추가하겠습니다.

인증 코드 흐름 !!!

• OAuth 클라이언트 역할을하는 웹 애플리케이션 서버가있는 경우
• 오래 살기 원한다면
• 데이터에 오프라인으로 액세스하려는 경우
• 앱의 API 호출에 대한 책임이있는 경우
• OAuth 토큰을 유출하지 않으려는 경우
• If you don't want you application to run through authorization flow every time it needs access to data. NOTE: The Implicit Grant flow does not entertain refresh token so if authorization server expires access tokens regularly, your application will need to run through the authorization flow whenever it needs access.

Implicit Grant Flow!!!

• When you don't have Web Application Server to act as OAuth Client
• If you don't need long lived access i.e only temporary access to data is required.
• If you trust the browser where your app runs and there is limited concern that the access token will leak to untrusted users.

---

From practical perspective (What I understood), The main reason for having Authz code flow is :

1. Support for refresh tokens (long term access by apps on behalf of User), not supported in implicit: refer:https://tools.ietf.org/html/rfc6749#section-4.2
2. Support for consent page which is a place where Resource Owner can control what access to provide (Kind of permissions/authorization page that you see in google). Same is not there in implicit . See section : https://tools.ietf.org/html/rfc6749#section-4.1 , point (B)

"The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request"

Apart from that, Using refresh tokens, Apps can get long term access to user data.

---

Which one is more secure and why?

Both are them are secure, it depends in the environment you are using it.

I don't see a reason why an extra step (exchange authorization code for token) is added in one work flow when the server can directly issue an Access token.

It is simple. Your client is not secure. Let's see it in details.

Consider you are developing an application against Instagram API, so you register your APP with Instagram and define which API's you need. Instagram will provide you with client_id and client_secrect

On you web site you set up a link which says. "Come and Use My Application". Clicking on this your web application should make two calls to Instagram API.

First send a request to Instagram Authentication Server with below parameters.

1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token. 

You don't send client_secret, You could not trust the client (The user and or his browser which try to use you application). The client can see the url or java script and find your client_secrect easily. This is why you need another step.

You receive a code and state. The code here is temporary and is not saved any where.

Then you make a second call to Instagram API (from your server)

 1. `grant_type` with the value of `authorization_code`
 2. `client_id` with the client identifier
 3. `client_secret` with the client secret
 4. `redirect_uri` with the same redirect URI the user was redirect back to
 5. `code` which we have already received.

As the call is made from our server we can safely use client_secret ( which shows how we are) with code which shows the user have granted out client_id to use the resource.

In response we will have access_token

참고URL : https://stackoverflow.com/questions/16321455/what-is-the-difference-between-the-oauth-authorization-code-and-implicit-workflo