먼저 이글은 제 개인의 경험을 기반으로 작성한 글입니다. 제가 미처 모르는 내용이 있을수 있습니다.

RestAPI는 왜 JWT를 써야 하는 걸까요?

- 전통적인 웹개발에서는 프론트/백엔드의 구분이 없습니다.(대신 웹퍼블리셔가 있죠^^)  

   모든 정보는 서버에서 처리됩니다. 클라이언트는 인증을 위한 최소 정보인 session_id만 쿠키값으로 가지고 있으면 됩니다.

- 백엔드/ 프론트를 구분하고, 둘간의 통신을 Restful API라는 방식을 추가하게 되었습니다. 사용자 인증은 중요한 이슈입니다. 그러나 여전히 웹환경입니다. 단일 서버이고, 하나의 인증정보로 여러 서비스와 연계되지 않습니다. 하나의 서비스입니다. 이 경우 그냥 기존 Cookie 방식의 Session 을 사용합니다.

웹브라우저라면 별다른 작업없이 처리됩니다.(브라우져가 알아서 Cookie  헤더를 보내주니까요.)

서버에선 session_start() 와,  $_SESSION 값만 처리하면 됩니다. 기존 작업에서 변경되는게 없죠.

만약 APP에서 RestAPI를 사용 한다면 어떨까요?(안드로이드, IOS...)

최초 로그인 API에서 session_id 를 token 으로 보내줍니다.

[code]

{

"status" : 200,

  "message" : "LOGIN SUCCESS",

  "token_data" : "xxxxxxx_session_id_value",

}

[/code]

(token_data는 세션아이디입니다. PHP에서 session_start() 이후에 session_id()로 조회가능합니다.) 

네이티브앱 클라이언트 에서 RestAPI를 호출할때 Http Header에 Cookie값을 추가합니다.

일바 브라우져에서 쿠키값 전송하듯이...

[code]

Cookie: PHPSESSID=xxxxxxx_session_id_value; 

[/code]

- 하이브리드 앱이라면 어떻게 될까요?

네이티브 영역에서 login처리후,,, 웹뷰의 PHPSESSID cookie값을 로그인결과로 받은 token_data로 설정합니다.

이러면, 그냥 웹브라우져의 세션인증방식과 동일해집니다.

[결론]

- 기존 웹브라우저의 Session 인증을 그대로 써도 아무런 문제가 없습니다.

   오히려 서버 코드를 기존 형태로 사용할수 있어서, 추가 작업이 필요없습니다.

- 완전히 API를 새로 설계한다면, JWT를 고려해볼만합니다.

- 그누보드 베이스에 Plugin 형태로 만드는 RestAPI는 그냥 Session을 쓰는게 바람직합니다.

- 이해하기 쉬운 코드가  좋은 코드입니다. 사용법도 편하다면, 더 좋은 코드입니다.

[참고글]

https://wjrmffldrhrl.github.io/JWT/