2023.01.18.WED

1. 프로그래머스 0단계

• 캐릭터의 좌표
  - 그냥 if문으로 걸러서 구현했다.

class Solution {
    public int[] solution(String[] keyinput, int[] board) {
        int x = 0;
        int y = 0;

        for(int i=0; i<keyinput.length; i++){
            if(keyinput[i].equals("left")) x -=1;
            if(keyinput[i].equals("right")) x +=1;
            if(keyinput[i].equals("up")) y +=1;
            if(keyinput[i].equals("down")) y -=1;

            if(x>board[0]/2) x = board[0]/2;
            if(x<board[0]/2*(-1)) x = board[0]/2*(-1);
            if(y>board[1]/2) y = board[1]/2;
            if(y<board[1]/2*(-1)) y = board[1]/2*(-1);
        }
        return new int[]{x,y};
    }
}

• 로그인 성공?
  • 회원 정보 조회. DB를 HashMap에 넣어서 풀었음.
  • if문의 순서가 중요하다. 처음에 키 먼저 확인 안 해서 NullPointException 발생.

import java.util.*;

class Solution {
    public String solution(String[] id_pw, String[][] db) {
        Map<String, String> map = new HashMap<>();

        for(int i=0; i<db.length; i++){
            map.put(db[i][0], db[i][1]);
        }

        if(!map.containsKey(id_pw[0])) return "fail";
        else if(!(map.get(id_pw[0])).equals(id_pw[1])) return "wrong pw";
        return "login";
    }
}

2. JWT(JSON Web Token)

• 자격 증명 방식(ex. 로그인 유지)
  • 세션 기반
    • 서버 측에서 세션 관리(in 세션 저장소)
      -> 상대적으로 보안(security) 유리
      -> but, 서버 부담 가중
    • 쿠키에 세션ID를 담아 HTTP 통신(HTTP header에 담음)
      -> 상대적으로 적은 네트워크 트래픽
    • 서버 확장 시, 세션 불일치 문제 발생 가능
      -> 해결 방법: Sticky Session(같은 서버로만 클라이언트 요청 전송), Session Clustering, Session 저장소의 외부 분리 등. (Redis 같은 RAM이어야 함. 하드디스크(DB)로 관리하면 조회 핵 느려짐. i/o 발생 가능)
    • SSR 방식 어플리케이션에 유용
  • 토큰 기반
    • 토큰 : 인증 수단, 마패
    • 인증된 유저 정보, 권한 등을 포함하므로 세션보다 많은 네트워크 트래픽 사용
    • HTTP header에 포함하며, 클라이언트 측이 저장(in local repository, cookie 등)
      -> 세션 보다 보안 측에서 불리
      -> 민감 정보는 토큰에 포함하지 않을 것
    • 서버 확장에 유리
    • 토큰 만료 전까지 토큰 무효화 불가능 (만료 시간 필수. 자동 삭제x)
      -> 해결 방법: Redis 같은 인메모리 DB에 무효화할 토큰의 만료 시간을 짧게 주어 해당 토큰을 사용하지 못하게 하기 등
    • CSR 방식 어플리케이션에 유용

• JWT = 액세스 토큰(Access Token) + 리프레시 토큰(Refresh Token)

  • 액세스 토큰(Access Token)

    • 리소스 접근 권한 부여. 짧은 유효기간 for 보안.

  • 리프레시 토큰(Refresh Token)

    • Access Token 재발급용 for 편의성. 상대적으로 긴 유효기간.

  • 구조

    • JSON 포맷
    • 각각의 요소를 base64로 인코딩(ASCII 변환)
    • Header.Payload.Signature
      - Header : 알고리즘, 토큰 타입.
      - Payload : 사용자 정보, 권한 등. (민감 정보 넣지 말 것)
      - Signature : 인코딩된 header, payload, 그리고 secretkey를 합쳐서 HMACSHA256 알고리즘으로 단방향 암호화. 토큰 검증에 이용됨

  • 절차
    

    - 클라이언트 요청
    -> 서버 확인. 토큰 생성(access, refresh)
    -> 서버가 토큰과 함께 응답 보냄
    -> 클라이언트가 토큰 저장
    -> 클라이언트가 토큰과 함께 새로운 요청 전송
    -> 토큰 확인 후 응답(토큰 안 맞으면 에러)

  • 장점

    • 토큰 하나를 여러 서버에서 사용 가능. secret Key만 알면 됨.
    • 토큰 생성처와 사용처가 무조건 같을 필요 없음.
    • 자격 증명을 직접 관리하지 않고, 다른 플랫폼 자격 증명으로 인증 가능

  • 의존 라이브러리

    • implementation 'io.jsonwebtoken:jjwt-api:0.11.5'
      runtimeOnly 'io.jsonwebtoken:jjwt-impl:0.11.5'
      runtimeOnly 'io.jsonwebtoken:jjwt-jackson:0.11.5'

  • Key key = Keys.hmacShaKeyFor(keyBytes);

    • jjwt 0.9 버전에서는 Signature 만들 때 HMAC 알고리즘을 직접 지정해야 했지만, 최신 버전에서는 내부에서 자동으로 알고리즘을 지정해줌

3. 기타

• BASE64의 의미 및 사용 이유(7bit인 ASCII의 바이너리 데이터 손실을 막기위해)
  https://devuna.tistory.com/41
• JUnit의 @TestInstance
  https://effortguy.tistory.com/119
• Token signature 암호화 방식(HMAC, RSA) 👍👍👍
  각각 대칭키, 비대칭키 사용한다는 게 가장 큰 차이
  https://medium.com/jongho-developer/jwt-algorithm-hs256-rs256-1ab9f833c486

<느낀 점>
오늘은 토큰에 대해서 공부했다.
흐름은 알겠는데, 아직 이론만 공부한 거라서 구현은 감이 안 온다.

컨텐츠 중간에 언급된 Sticky session 등에 대해 궁금했는데,
세션 관련 인프런 무료강의 20분짜리가 있어서 봤더니 도움이 되었다.

어제오늘은 학습량이 좀 널널했는데, 방금 블로깅 하면서 내일 공부할 컨텐츠 잠깐 봤더니 양이 엄청나다. 이걸 또 하루에 후려넣다니,,^^
양 조절 실패와 급발진 그 사이 어딘가..ㅎ

미리 조금 보다가 자야겠다.

알고리즘은 조금씩 해나가고 있다.
많이 풀어보고 고민해보는 게 최선인 것 같다.