IdentityServer 흐름

IdentityServer 흐름

---

IdentityServer는 Flows 열거형에 정의되고 클라이언트에 대해 설정된 다양한 OpenId Connect 흐름을 지원합니다 . 또한 각 유형의 흐름에 대한 샘플과 문서에 이에 대한 많은 참조가 있지만 문서 에서 흐름이 무엇인지에 대한 간단한 정의 목록을 찾을 수 없었 습니다. 하지만 그렇지 않은 것 같아요. 이들의 차이점에 대해 더 자세히 말씀해 주시겠습니까? 문서에 추가할 수 있습니까?

무엇 그래서 : 암시 적 흐름, 자원 소유자 암호는 자격 증명 , 흐름 인증 코드의 흐름을, 클라이언트 자격 증명 , 흐름 정의 보조금 흐름 및 하이브리드 흐름을? 또한 어떤 것이 OAuth 흐름이고 어떤 것이 OpenID Connect 흐름입니까?

감사 해요!

---

나는 동일한 문제에 직면했으며 현재 작업이 계속 진행 중입니다. 문서를 마치면 여기에 게시할 수 있습니다. 당분간: 초안을 확인하십시오:

OIDC 및 OAuth2 흐름 섹션 #73으로 IdentityServer 문서 강화

업데이트: OIDC 및 OAuth2 흐름

---

minimumPrivilage의 첫 번째 링크에서: 및 Aharon Paretzki의 OAuth 2 Simplified

흐름은 ID 토큰 (예: 인증 코드) 및 액세스 토큰 (예: '토큰')이 클라이언트에 반환되는 방식을 결정합니다.

Authorization Code Flow : OAuth 2.0 Flow

• 인증 엔드포인트에서 인증 코드가 반환됩니다.
• 모든 토큰(승인 코드와 교환하여 두 번째 단계로)은 토큰 끝점에서 반환됩니다.
• 클라이언트 비밀의 기밀성을 유지할 수 있는 서버 기반 호출(API)에 사용됩니다. 아무도 "클라이언트 비밀"에 액세스할 수 없는 한 더 강력한 보안을 허용합니다.

암시적 흐름 : OAuth 2.0 흐름

• 모든 토큰은 Authorization Endpoint에서 직접 반환됩니다.
• 토큰 끝점이나 인증 코드가 사용되지 않습니다.
• 모바일 및 웹 기반 앱에 사용되며 클라이언트 비밀의 기밀성을 유지할 수 없으므로 인증 서버 자체에서 토큰을 발급받아야 합니다. 이는 덜 안전 하며 API 사용에 대한 암시적 흐름 호출 을 거부 하고 브라우저 기반 및 모바일 기반 앱에만 허용하도록 서버를 설정하는 것이 좋습니다 .

Hybrid Flow : OAuth 2.0 Flow

• 인증 엔드포인트에서 인증 코드가 반환되고,
• 일부 토큰은 인증 끝점에서 직접 반환되고 다른 토큰은 토큰 끝점에서 (인증 코드와 교환하여 두 번째 단계로) 반환됩니다.
• 두 흐름이 모두 필요한 곳에 사용됩니다.

---

사양을 참조하십시오 - 이미 모두 작성되었습니다.

http://openid.net/specs/openid-connect-core-1_0.html 및 http://tools.ietf.org/html/rfc6749

또한 최근에 다양한 응용 프로그램 유형에 대해 요약한 요약을 작성했습니다.

http://leastprivilege.com/2016/01/17/which-openid-connectoauth-2-o-flow-is-the-right-one/

---

OAuth2에 정의된 흐름 은 클라이언트가 access tokenID 제공자 서버에서 수신하는 몇 가지 방법일 뿐입니다 . IdentityServer이 경우이다. , , , 와 같은 플로우 다이어그램에 지정된 엔티티를 완전히 이해하지 않으면 플로우를 이해하기가 쉽지 않습니다 . 여기에 이러한 엔터티(역할, 중요)에 대한 간략한 설명이 있습니다 .Resource OwnerUser AgentResource Server

---

인증 코드 흐름 : authorization code를 발행하기 전에 발행합니다 access token.

• 클라이언트는 다음을 요청합니다. authorization code.
• IdentityServer 는 클라이언트의 유효성을 검사하고 리소스 소유자에게 authorization code.
• 그런 다음 클라이언트 access token는 주어진authorization code
• 인증 서버access token 는 클라이언트에 직접 발급합니다 .

---

암시적 코드 흐름 : 제공 access token되지 않아도 문제가 발생합니다 authorization code.

• 클라이언트가 access token직접 요청합니다 .
• IdentityServer 는 클라이언트 유효성 검사를 건너뛰지만(일부 시나리오에서는 부분적으로 수행함) 여전히 리소스 소유자에게 발급 권한 부여를 요청합니다.access token
• 이 흐름은 authorization code.

암시 적 흐름은 같은 스크립트 언어를 사용하여 클라이언트를위한 이상적인 흐름으로 간주 javascript클라이언트가 요청을하지 않기 때문에 authorization code하고 access token클라이언트에 대한 하나의 네트워크 왕복을 줄이고, 차례로, 별도.

---

클라이언트 자격 증명 흐름 : access token리소스 소유자의 허가 없이 발급합니다 .

• 클라이언트가 액세스 토큰을 직접 요청합니다.
• IdentityServer 는 클라이언트의 유효성을 검사하고 access token즉시 발급합니다 .

이것은 클라이언트가 리소스 소유자이기도 한 경우에 이상적이므로 access token.

---

리소스 소유자 흐름 : access token클라이언트에 리소스 소유자의 자격 증명(예: Id / Password)이 있는 경우 발행

• A client requests an access token directly.
• IdentityServer validates the client and checks the resource owner's identity.
• If valid, the client gets access token instantly.

This flow is ideal for the clients that you believe it is absolutely safe to share the ids and passwords with them.

---

Hybrid flow (OIDC flow) : issues an authorization code and an access token.

This is a combination of Authorization code flow and Implicit code flow. That's why it's called Hybrid.

---

Custom flow

This is literally a customizable flow. This can be used when you need a specific authentication / validation process in your business beside all the protocol specifications in OAuth2.

IdentityServer is well aware of this kind of situation and it supports extensibilities by design. The factory pattern, the decorator pattern, and IoC / DI will be making easier for you to implement additional features on your IdentityServer.

ReferenceURL : https://stackoverflow.com/questions/29683624/identityserver-flows