β¬οΈ Main Note
https://docs.google.com/document/d/13llzeozWp18zFTeBqWb2DSq36BP9tB3SWWhCMXMZkqw/edit
Scale up = enlarging a computer's memory
Scale out = creating multiple computers
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.
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.
const aaa = {accessToken}
bearer ACCESSTOKEN
to backendWhen 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.
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
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.