1.AAA architecture

AAA(Authorization, Authentication, and Accounting)아키텍처는 인증(Authentication), 인가(Authorization), 그리고 회계(Accounting)와 관련된 개념을 포함하는 보안 아키텍처입니다

위키: https://en.wikipedia.org/wiki/Authentication_protocol

1.authentication (인증)

• 인증 : 사용자의 신원을 확인하는 행동 ex) 회원가입,로그인 ex) 대리 운전사가 내 자동차의 키를 받아서 잠시 일시적으로 자동차를 운전할 수 있는 권한이 있음

Authentication is 
 is the act of proving an assertion, such as the identity (신원)
  of a computer system user.
   (컴퓨터 시스템 사용자의 신원과 같은 주장을 증명하는 행위)

1. 유저가 로그인 시도
   • login 뭐야? 로그인은 사용자의 인증(Authentication)과 관련된 과정이며 자신의 신원을 확인하고 인증하는 과정
2. 서버상에 일치하는 유저 정보를 찾는다
3. 찾았다면 인증(authentication)확인의 표시로 (세션 or 토큰)을 빌급/전달
4. 웹 브라우저 (세션 or 토큰) 관리하고
5. 새롭게 서버로 요청을 보낼 때 인가(authorization)하기 위해 세션/토큰을 함께 보낸다. 출처

Authentication(인증)에는 다양한 인증 방식이 있으며, 이러한 방식들을 구현하기 위해 다양한 프로토콜이 사용됩니다

대표적인 인증 방식

1. HTTP 기반 인증
2. 토큰 기반 인증
   • jwt (json web token) 토큰 기반 인증 인증을 위한 토큰 토큰 사용자인증을 위한 정보를 서명한 것

   JSON Web Token  is a proposed Internet standard for creating data with optional signature and/or optional encryption whose payload holds JSON that asserts some number of claims.
   The tokens are signed either using a private secret or a public/private key.
   //https://en.wikipedia.org/wiki/JSON_Web_Token

   jwt 인코딩/디코딩? jwt.io 사이트에서도 jwt 토큰을 디코딩한 결과를 알수 잇다. 이처럼 지금 사이트는 서베에서 디코딩해서 토큰안에 정보를 얻음 cookie의 사용을 제거 토큰 등의 정보를 cookie로 저장하면, domain 기반으로 불필요한 cookie가 전달되어 예상치 못한 오류를 야기할 수 있다. 이런 경우 cookie 대신 HTML5 spec에 있는 Web Storage(Session/Local storage)를 사용하는 것이 더 일반적4

   • Bearer 인증 방식 HTTP 프로토콜을 사용하여 인증 처리를 하면서도 OAuth 프로토콜을 사용하는 인증 방식을 구현한다. Bearer 인증은 HTTP 요청 헤더에 ("Authorization" 헤더) "Bearer"라는 문자열이 포함된 액세스 토큰을 서버에 전달(HTTP 프로토콜을 이용) OAuth 프로토콜은 클라이언트가 인증되고 액세스 토큰을 얻는 데에 사용되며, Bearer 인증은 이를 구현하는 하나의 방식
3. OAuth
   • OAuth 1.0
   • OAuth 2.0 => 베어러 토큰을 사용하여 인증

2. authorization (인가 방식)

• 인가하다(대상이 옳음을 소상하게 밝혀 인정하다.)
• 권한 여부 확인
• 인증(Authentication) 된 사용자는 인가(Authorization)를 통해 특정 리소스에 대한 접근 권한을 부여받고, 해당 리소스를 이용하

  Authorization is the function of
   specifying access rights/privileges to resources,
    which is related to general information security and computer security,
     and to access control in particular.
      ( 접근 권한/특권, 특히 접근 제어를 지정하는 기능)

실제로 적용한 방식

지금 사용하는 시스템은 JWT 기반의 인증을 사용합니다. 현재는 클라이언트에서 아이디,패스워드를 보내면 서버가 응답값으로 jwt token(aceess token ,refresh token) 을 보냅니다. 클라이언트는 로컬스트로지에 jwt token 을 저장하고 있으면 jwt 토큰은 주기 짧아 refresh token 도 같이 사용하고 있다. https:/.outsider.ne.kr/1160

* ### [계정 service],[resource service],[client] 를 이용한 로그인

* ### [client] 로컬 을 실행하고 [service] 개발계 의 DB와 API 사용하기
일반적이진 않지만 화면 개발을 해야 하는데 서버 개발이 늦어져서 개발계에 서버와 연동해서 작업을 했었다.
(이때는 서버가 보내주는 json 값이 일치 했기 때문에 가능했다.)

> 1. [client]에 로그인 하면 아이디,패스워드로 jwt 토큰을 [계정 service] 에 요청합니다.
2. [계정 service]에서 jwt token 을 만들 때 [개발계의 JWT]랑 똑같도록 변경하는 작업 진행
3. [계정 service] 는 [개발계의 JWT]을 화면에 전달합니다.
4. 로그인한 사용자는 [개발계 서버의 API]를 조회할때 [개발계의 JWT]을 사용

세션/토큰 비교

<세션>

• 서버측에서 저장/관리
• 유효기간,HttpOnly,Secure 옵션 주어 쿠키 저장
• 세션? 서버가 사용자의 정부를 저장해야헸고 이를 세션이라고 불렀다 대부분 세션을 메모리에 저장했고 로그인중 사용자가 많아지면서 db나 서버에 무리를 주었다.

<토큰>

• 웹 브라우저에 저장
• 세션보다 공격 노출 더 크다
• 되도록 민감한 정보를 담지 않도록 한다
• 만료 기간 설정 가능
• 토큰 주기가 짧을 때 refresh token 을 인증과정에 추가적으로 발급

20240318

"token from cookien:http: named cookie not present 에러 발생 https://risus.tistory.com/18 ???

참고

https://mangkyu.tistory.com/55 Refresh token 설명 영상 https://velog.io/@gusdnr814/%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%9D%B8%EC%A6%9D-4%EA%B0%80%EC%A7%80-%EB%B0%A9%EB%B2%95