인프런 커뮤니티 질문&답변

현재 두개의 시크릿키 client 와 frontSecret 키들이 있잖아요.

 

1.

clinentSecret 키는 서버간의 인증을 위한 키 

frontSecret키는 프론트에서 서버로 보내줄때 인증을 위한키

보안상의 이유로 클라이언트 키가 프론트에서 보이는 것 보다

프론트 키가 프론트에서 보이는 걸 선호하는 이유가, 프론트키 와 유저가 직접입력한 도메인을 알아야 기에 좀 더 안전해서 프론트 키를 쓴다. 

지금 제가 이해 한게 맞나요?

 

2.

현재 프론트에서 보내는 프론트 키 + 도메인으로 토큰을 발급 받을때요. 

localhost:8003/ 을 입렵하면, 

라우터 / 이거 에서 frontSecret 키를 main.pug 로보내고, 

main.pug는 다시 locallhost:8002/v2/token 으로 보낸후, 

이 라우터 안에서

DB에 제대로 유저가 등록한 도메인으로 요청을 했는지,

where: { host: url.parse(req.get('origin')).host } 로 

DB 체크후  CORS로 넘겨진후..

 

/token 라우터로 가서, 보내준 frontKey가 맞는지 체크하고 

토큰을 발급을 해주잖아요. 

그래서 /token 라우터 코드를 

const { frontSecret } = req.body; 프론트키받고

where: { frontSecret }  이런식으로 DB에서 체크후 

DB에 프론트키가 있는지 여부를 보고, 토큰을 발행해주나요. 

 

그렇다면, 이전에 clientSeceret 키로 주고 받았잔아요.

예를 들면, nodebird-call 을 보시면, 

request 함수에, 

 

이런식으로 axios를 통해서 http://localhost:8002/v2/token 에다가, clientSecret을 

보내고, 위와 같은 흐름으로 client 키를 통해서

v2.js 에서 도메인도 체크하고난후, 

/token 라우터를 통해서,  

const { frontSecret } = req.body; 프론트키받고

where: { frontSecret }  이런식으로 DB에서 체크후 

체크를 하는데 , 문제는 frontSecret을 받으려고하잖아요.

 

이럴경우는 clientSecret을 따로 받을 수 있게, 

v2-1.js 이런식으로 새로 만들고,

아예  http://localhost:8002/v2-1/token 이런식으로 요청을 받을수 있게 하는게 나은가요 ??

 

3. 그리고, 만약에 clientSecret만 으로 토큰을 

받는다면, 도메인 체크는 할 필요가 없어지는게 맞죠?

애초에 프론트에 나오지 않아 해킹에 위험이 적어지니까요.