Have you been studying for an AWS certification and have yet to actually test? Now might be the time. AWS is currently offering free retakes of their certification exams. Here are the relevant details:
- You must take your exam from January 15 to April 15, 2024
- You must sit your retake before June 30, 2024
- You must use the appropriate promo code – you can receive it here – https://home.pearsonvue.com/aws/freeretake
Enjoy this great opportunity – and consider pairing it with my AWS Udemy resources 🙂 Here are 50% vouchers for those products:
AWS Certified Cloud Practitioner CLF-C02 Practice Exams
AWS Certified Solutions Architect Associate 2023 Edition!
OAuth is defined in RFC 6749. It was designed with HTTP in mind and permits a user to login to multiple web sites using a single user account credentials. A classic example is logging in to a corporate website using the credentials available in Facebook.
NOTE: There are two versions of OAuth (1.0 and 2.0) and these versions are not compatible. OAuth 2.0 is the current adopted standard.
OAuth defines four roles:
- Resource owner – this is typically the end user, but it can be any system or computer
- Resource server – the host of the secured accounts; the server responds to the client
- Client – the application making a resource request
- Authorization server – the server that issues access tokens to the client once identity is verified
There are two flows types with OAuth. There is a two-legged authentication style that does not feature a resource owner. This is the type of flow you will often find when APIs are in use. This post focuses on the DevNet Pro exam objective of the three-legged authentication style that does feature the resource owner.
Here are the steps we must know in this OAuth three-legged authentication process:
Step 1 – the resource owner sends a request to the OAuth client application
Step 2 – the client application sends the resource owner a “redirect” to the authorization server
Step 3 – the resource owner connects directly with the authorization server and authenticates
Step 4 – the authorization server presents a form to the resource owner to grant access
Step 5 – the resource owner submits the form to allow access
Step 6 – the authorization server sends the client a redirection with the authorization grant code or an access token
Step 7 – the client application sends the authorization grant code, client ID, and the certificate to the authorization server
Step 8 – the authorization server sends the client an access token and optionally a refresh token
Step 9 – the client sends the access token to the resource server to request protected resources
Step 10 – the client can now access the protected resources on the resource server