.Net 인증 허가에 대한 개인차

몇달동안 Authorization , Authencation , jwt 지옥에서 살면서 느낀것데
이건 좀 어려운 개념 아닐까 싶네요
원래 정석대로 하면
사전에 Scaffold로 ef identity schema DB 에 만들고
services.AddIdentity<ApplicationUser, IdentityRole>()
.AddEntityFrameworkStores()
.AddDefaultTokenProviders();
services.Configure(options =>
{
// Password settings~~ 생략

그다음에 Middleware 에서
app.UseAuthoriaztion()
app.UseAuthencation()

하고 view 에서는 signmanger ,usermanager 로 멤버쉽 관리하고 등등

이렇게 알려준 메뉴얼 대로 하면 돌아가는구나 하면 쓸수 있습니다.

문제는 ?? 여기에 좀 이상한 요구사항이 오면 그때부터 꼬이기 시작하고
function 하나하나 보면서 이 option 을 다양하게 적용하면서 맞춰 봐야했습니다(제경우에는)

구글인증이나 카카오 인증을 넣을려면 이걸 어디서 부터 만져야 하는지
EF Identity 스키마를 못쓰고 기존 DB Schema를 재활용 할려면 또 뭘 만져야 하는지
Controller 가 아닌 일반 static file 에 접근 권한은 또 어떻게 …ㅠㅠ

oidc jwt 인증을 할려면 또 바꿔야 하는지 그리고 조금 부끄럽지만 ;;
미들웨어 순서도 중요하네요

또 ;; 이게 blazor spa로 가면 바뀌고 두서없이 적었지만
기존에는 그냥 있는데로 쓰다가 뭘 좀 바꿀려면 찾아봐야 할것이 참 많은 느낌입니다 .

제가 못나서 그런것겠지만 와 이건 간단하지 않더군요
그리고 deep 하게 파고 들어가면 뭔가 접근할수 없는 부분도 있는것 같구요

뭔가 이건 .Net 을 익히는데 있어 루키 개발자나 윈폼 다루는 개발자가 하기에는
허들인것 같습니다. 물론 익숙해지면 참 삽질을 많이했구나 느끼겠지만요
아직 까지 접근하지 못하고 이해 안가는 부분이
[Authoriazation] 속성을 줬을때 도대체 내부에서 무슨일이 일어나는지 모르겠습니다.

더불어 EF Identity 의 대한 이해가 없는 고객사나 개발자랑 일할때
DB에 table 촤르륵 생기니까 이것 뭐냐고 설명하는것도 난감하고 2factor 적용할려면 또 찾아봐야 되고 ㅠㅠ

정리하면 EF Identity, Authencation,Signmanager, claim ,role,oauth , middleware
하나하나 확실한 개념을 세우고 가야 하는것 같습니다.

그리고 이 개념을 전파해야 하는 입장에서 그냥 쓰세요 할수도 없고 ^^;; 일일이 설명해줘야 하는데
정확히 ? 모르겠고요

그냥 옛날에 간단하게 할때는 session이나 cookie 에 key 넣고 master 페이지에서
check 만 하면 솔직히 아무 문제 없이 쓰긴 했죠 (그게 맞다는것 아닙니다 ^^)

4개의 좋아요

예전에 .Net 5.0에서
app.UseAuthoriaztion()
app.UseAuthencation()
이렇게 하니 인증에 문제가 생겨서 반대로
app.UseAuthencation()
app.UseAuthoriaztion()
이렇게 순서만 바꾸니 해결된 적이 있습니다.

원인은 아직도 모릅니다. ㅎㅎㅎ

2개의 좋아요

Asp.Net Core Identity 를 깊게 파고 나서도 드는 생각은 구조화의 정도가 너무 심하다는 것이었습니다.

인증/인가의 처리는 미들웨어에게 맡기고, 그 미들웨어가 사용하는 인증 방식(Authentication Scheme)이나 인가 정책(Authorization Policy)은 별도로 서비스로 등록하게끔 되어 있고, 요청 핸들러 별로 인가 정책을 차등 적용할 수 있도록 만들어 놓았죠.

너무 촘촘히 짜여져 있습니다.

그러나, 이렇게 고도화된 구조는 Asp.Net Core 에서만 유효하다는 함정이 있습니다.
심지어 같은 회사에서 만든 Blazor 에 바로 사용하지도 못해 Authentication Provider라는 중간 객체를 추가했습니다.

아직 자세히 살펴보지는 않았지만, .net 8.0에서는 미들웨어 중심에서 벗어나 서비스 중심으로 재편된 것 같습니다.
그 결과로, 블레이저도 서비스 컨테이너가 있으니 중간 객체를 생략해도 될 것 같다는 생각이 들기는 합니다.

4개의 좋아요

인가(Authorization) 미들웨어는 HttpContext.User 의 소비자이고, 인증(Authentication) 미들웨어는 생산자이기 때문입니다.

즉 인증 미들웨어가 HttpContext.User 에 값을 먼저 할당해줘야 인가 미들웨어가 이 값을 바탕으로 허락/거부를 수행하는 구조입니다.

그래서 항상 인증 미들웨어가 인가 미들웨어보다 앞 자리를 차지해야 합니다.

3개의 좋아요

무엇보다 제일 무서운것 이렇게 생고생 하면 익숙해지면 차기버전은
또 바꾸겠지요
차기 버전을 보면 service 를 block 화해서 패키지로 만들어서 쓰는것 같은데
그리고 기본 인증 UI 를 제공해서 처음의 접근성은 쉬울지 모르나
이걸 모르는 상태에서 이게 왜 나오지 하는것도 많구요

3개의 좋아요

제 생각은 좀 다릅니다.

Asp.Net Core Identity 의 구조는 마이크로소프트가 생각하는 "서버라면 이 정도의 인증/인가는 해줘야지"라는 개념을 매우 잘 드러내고 있다고 생각합니다.

우리에게 부족한 것은 그 개념을 못 따라 가고 있다는 점입니다.

우리가 개념을 이해하는데 어려움을 겪는 이유 중 가장 큰 것은 마이크로소프트의 시니컬한 문서 태도라고 생각합니다. (특히 Rick Anderson…)

쓰는 것은 내 자유요… 이해하는 것은 너의 의무이니라…

특히, 자기도 개념을 모르면서 이상하게 번역한 한국어 책/문서들도 어려움을 키우고 있다고 봅니다.

3개의 좋아요

그러게요 무엇보다 문서화가 잘되있고 아티클이 많은것 같지만 거의 성공사례 위주로 소개 하는데 이건 반대로 ? 실패 사례 위주로
이것이 왜 안됬는지? 그리고
다양한 업무 환경에 example이 좀 많았으면 합니다.
그리고 문제 해결을 위해서 단편적으로
이것 고치면 되 아 그것 미들웨어 순서 바꾸면 끝 ? 끝나는것이 아니라 관련해서 전체적으로 어플리케이션 영향도를 잘 설명해주면 좋겠다는 바램입니다.
아 이건 결국에 이것 관련해서 개발자 가 많이 덤벼들어야 해결 될것 같긴 하네요

3개의 좋아요

아유… 고생이 많으셨군요…

저도 Store의 존재까지 파고 나서야 그제서야 코끼리 다리 정돈 만진 느낌입니다.
IdentityManager → IdentityStore → DataLayer 를 커스터마이징해서 구현 해 볼 일이 생겼거든요.
뒤따라 오면서
Role, User도 커스텀 하게 되면서
AspNetxxx 어쩌고…하는 EF Identity 테이블을 굳이 생성하게 두지 않아도 사용 할 수 있는 단계까진 온 것 같습니다.

그럼에도 불구하고, 아직 jwtbearer 기반이나, cookie 기반의 인증 유지 방법은 여전히 모르겠습니다;;

저도 위에 부분을 손 대게 된 이유 중 하나가
기존 DB 스키마를 사용 해야 하는 상황이었고 (일종의 마이그레이션이 아닐까요?)
기존 Identity용 페이지들이 전부 scaffold된 razorpages로 생성되는 바람에
blazor와 맞지 않게 Controller 와 HttpContext를 써야 했던 탓도 컸었어서
아예 로그인 페이지를 새로 만들어서 썼었습니다.
완성도는 별개로요 ㅠ.ㅠ

8.0 와서는 Identity기능도 전부 razor component로 바뀌어서 좀 더 blazor 친화적으로 바뀌었는데
프로젝트 템플릿에서 Identity를 체크해버리면 모든 페이지를 잔뜩 다 생성버려서.
그건 쪼끔 귀찮네요 ㅠ.ㅠ

3개의 좋아요