You probably didn't get a full story because there
isn't a full story. OAuth is a standard with a very high abstraction level, it leaves a lot of implementation details to authentication providers. For instance, OAuth says nothing about JWT tokens. JWT token are just one of the many ways you can implement data
exchange between hosts.
JWT tokens come in different flavours. Transparent JWT tokens contain information like the user ID that was authorized. When you're using these you don't have to store any tokens anywhere, in theory. Your server just validates the token, checks that it hasn't expired, and then does with the user ID from the token what it wants. The client could theoretically request a new token before every request and nothing would get stored. It's common for the client to save the token in a cookie or user session though.
Opaque tokens don't contain information that is accessible by the web service. The web service must present the token to the authentication provider that generated the token, which will then validate the token and return a user ID or other info back to the web service. In this case, the authentication provider must store data that's associated with the token. It may still store data in the token itself, but it will encrypt the token to make it unreadable to anyone but itself.
tangara goh wrote:And also after the JWT token is verified, how is the User being transported to a 3rd party that is using OAuth2 ?
If the web service validates a transparent token, the user info will be present in the token itself.
If the token is opaque, it must be traded for user information with the authentication provider.
Furthermore, how does it take place in a AWS setting?
What exactly do you want to achieve?
