πŸ“ BE TIL Day 22 0412

j00b33Β·2022λ…„ 4μ›” 19일
0

CodeCamp BE 02

λͺ©λ‘ 보기
22/30

⬇️ Main Note
https://docs.google.com/document/d/13llzeozWp18zFTeBqWb2DSq36BP9tB3SWWhCMXMZkqw/edit


🏁 DAY 21 REVIEW

Scale up = enlarging a computer's memory
Scale out = creating multiple computers

  • To do so, memory session was moved to database
  • If memory session is inside backend server, that's stateful.
  • To make it stateless, scale out should be done.

After making the server stateless, traffic increased to database, so what we did was load balancing (λΆ€ν•˜λΆ„μ‚°).
DB is also a disk-based, so redis was used to reduce the traffic.
--> Redis is memory base
But to use Redis, we had to put redis one by one in front of each databases, so this was inefficient. Thus, we used JWT.


☁️ RefreshToken

Authentication(인증): Validation
For those of APIs that need uesr-login, we had to authorize(인가) those users.
For authorization, accessToken must be beared as bearer form inside http request header.
Then backend API encoded accessToken and the authorization happened.
--> At this point, if wrong accessToken was sent, "UNAUTHORIZED" error message was sent.

Today, think about when the accessToken is expired.

In response, there also exists header. Inside header, there is redirection command: "/login"
This redirection command is executed when accessToken is expired, so sending redirect command in response to make sure the user logs in again.
--> But making the user to keep log in again is an inefficient service. So here we create refreshToken

When a user logsin in a browser, email and password is sent to backend from the browser.

Meantime, backend creates two JWT (JSON WEB TOKEN); those two tokens are sent to frontend.

  • One for payload to make sure the status, and the other to the cookie storage inside the browser.
    --> Cookie Storage: refreshToken // Payload: accessToken
  • Browser saves this accessToken inside a variable --> const aaa = {accessToken}
  • Browser sends bearer ACCESSTOKEN to backend
  • Cookie storage can connect frontend and backend server. (Cookie is automatically sent to backend server)

⚠️ ERROR: UNAUTHENTICATED

When an accessToken is expired, error should be thrown: UNQUTHENTICATED
Error is thrown like this:onError(){ "// error logic" }
Inside this error logic, restoreAccessToken API should be created, and backend API verifies refreshToken and creates new JWT
RefreshToken is sent so new accessToken is reissued.
--> If I make the refreshToken to expire period as every month, then there's no need to reissue the refreshToken.

If an accessToken is saved in localStorage, I can call the data in a form of object.
Cookie vs. local : Cookie storage is available to put diverse options and secure.

🎐 Login Structure Flow

  1. User logs in inside a browser with his/her email and password.
  2. Backend creates accessToken with the user's email and password.
  3. That accessToken is sent to frontend.
  4. Frontend server puts accessToken inside the header with bearer and sends requests(regarding the API that needs login).
  5. Then backend server receives the accessToken and decodes it.
    • At this point if this accessToken is expired, backend throws error UNAUTHENTICATED : FAILED TO VALIDATE THE USER
    • If authorization failed, restoreAccessToken API is executed
      --> refreshAccessToken is sent to frontend

Short Sequence :
1. Authentication (인증)
2. Authorization (인가) : AccessToken from Frontend to Backend
3. If expired, refreshAccessToken
4. createBoard() API or else APIs that require login is executed


☁️ Social Login

API source code can be partitionized : "Micro services"
Micro Service is composed with resource services.
--> Resource service = productservice, authservice, userservice

And google is sharing auth service for social login.
By using google auth service, backend can get the user information : profile pic, name, and email.
--> Once the user logs in, with these information, accessToken and refreshToken is created. (But we can also use google-privided accessToken and refreshToken)

This open auth service is call Open Authentication (μ˜€ν”ˆμΈμ¦) == Social Login
--> Google login, Naver login, Kakao login, etc...

If the user want to log in as google account, then the server redirects the user to the google log in page.


profile
μ½±γ…†l

0개의 λŒ“κΈ€