나는 닷넷 코어 WebAPI 인증을 초보자입니다. 나는 OpenIddict가 사용하기 쉬운 인증 서비스 중 하나라는 것을 알았지 만 사용하기 전에 GitHub에 다른 인증 흐름을 가진 샘플이 있음을 알게되었습니다. 이러한 인증 흐름을 둘러싼 문서를 찾을 수 없으므로 다음 질문에 유의하십시오. 누군가 해당 지역에 대한 통찰력을 제공 할 수 있다면 감사하게 생각하십시오. GitHub의 URL이 : https://github.com/openiddict/openiddict-core왜 OpenIddict에는 많은 인증 흐름이 있습니까?
는 이유 하나를 사용 ... 다른 흐름이있다? 나는 각각의 흐름이 적용의 다른 성격에 맞을 것이라고 짐작한다.
a. 각 흐름의 장단점은 무엇입니까?
b. 해당 특정 응용 프로그램에 적합한 올바른 옵션 (인증 흐름)을 결정하는 데 도움이되는 모범 사례 또는 지침이 있습니까?
미리 감사드립니다.
왜 다른 흐름이 있습니까? 어느 것을 사용해야합니까?
OpenIddict는 OAuth2/OpenID Connect 서버입니다. 따라서,이 두 사양에 의해 정의 된 모든 고전적인 코어 흐름을 구현합니다. 당신이 알아 낸 것처럼
각 흐름은 다른 사용 사례가 있습니다
머리가없는 클라이언트 응용 프로그램이 자신의 리소스에 액세스해야 할 때 자격 증명을을 부여 클라이언트가 사용됩니다. 기본적으로 서버 대 서버 시나리오 인이 흐름에는 사용자가 관여하지 않습니다. 클라이언트 응용 프로그램은 사용자 이름과 사용자의 암호 토큰 요청을 보내고는 액세스 토큰을 다시 가져옵니다
자원 소유자 암호 자격 증명 가장 간단한 OAuth2를 흐름이다 부여합니다. 이 흐름은 때로는 '기존'흐름으로 간주되며 클라이언트가 사용자 자격 증명을 알고있는 유일한 흐름이므로 직접 관리하지 않는 타사 앱에서는 사용하지 않아야합니다.
코드 흐름은 리디렉션을 사용하여 사용자가 자신이 이제까지와 함께 자신의 자격 증명을 공유하지 않고 클라이언트 응용 프로그램에 대한 액세스 권한을 부여하고 싶어 여부를 결정할 수있는 동의 페이지를 만들 수있는 가장 복잡한 OAuth2를/오픈 ID 연결 흐름이다 앱.
암시 적 플로우은 브라우저 기반 앱용으로 작성된 간단한 코드 플로우입니다.
자세한 내용은 http://kevinchalet.com/2016/07/13/creating-your-own-openid-connect-server-with-asos-choosing-the-right-flows/을 참조하십시오.