The password anitpattern

->The email server protects access to the email using a password.

-> This password only known to JOE. It’s not available on the email
scheduling app.

-> Email scheduling app has been written by 3rd party developer.

-> Just provide the key the password to the third party app, and now th e
3rd party app can access Gmail and email and everything happily.
-> It can even store the password in some kind of hash.

-> its very dangerous from a security perspective.

-> it can do a lot of thing with that password, can be used for some other
google services.
Solution for the above problem.

-> Additional actor in this scenario is Oauth server.

-> Email Scheduling app does not directly contact the resource server to
access emails.
-> ESA now will call Oauth server.
-> Oauth server first asks the resource owner to allow access to resources.
So it goes and sends a log in screen to resource owner, it goes by a web
browser and send it to joe.
-> So the server manages to open up a web browser and on this web
browser it displays a login screen.
-> Server validates and authenticate the resources owner.

-> If its correct and then it sends back a token.

-> The token is created by the Oauth server, and its just a bunch of number
OAUth component

-> Actors
-> Oauth designed for distributed system that possess of several actors
with distinct roles.
-> Oauth providers (oauth servers)
-> Resource providers. (Web apis)
-> Resource owner. (user, end user)
-> Client. (cloud app or mobile app)

Oauth provider
-> Oauth provider consists of 3 components that are together called the
server.
a) Authentication component: It basically provides log in a log page that
can be displayed on a web browser.
-> Idenity provider and all the identity and access management
infrastructure that is in the backend.

b) Consent server:
-> for requesting the authenticated users consent for the delegation of
access right to the client.
-> and this is the component usually pops up right after click on social
icons.
-> displayed another page which contains information like do you really
want to provide this information off yours to a 3rd party apps.

c) Token management infrastructure.

-> These are basically database or it’s one database which maintains all the
tokens that has been given out from the oauth provider, so they can later on
be requested for validation or even for relocation.

Resource Provider
-> makes a protected reosource available by a http protocol.
-> The resource may be data service and is often offered in the form of a
Web api which in turns offers the protected data.
-> one of the first things that the web api needs to do for each incmoing
request is this checking the validity of the provided access token.
Resource owner
-> is the owner of the protected resource.

- 4rd party access the data in the name of the resource owner

Client
-> the client is an application that it tends to access a protected route.
-> the client can be web application, mobile app and a clound

Oauth actors in detail

-> A resource owner name (JOE) owns a resource, he has access to this
resource and he holds credentials which allow him to get access to that
resource.
-> there is also a client which is a 3rd party application which also wants to
have access to specific resources which are owned by the resource owner.
-> the Oauth server manages the identity of all involved other actors.
Verifies this identities and then creates tokens also verifies these tokens for
these services.
-> there are two endpoints which the Oauth server provides.
a) Authorication End point
b) Tokenend point

-> The resource server provides the resources which are owned by the
resource owner, and which are requested by the 3rd party app by the client.
-> The resource server also protec these resources and only give acces
either if you have password, or if you have tokens

Resource Owner
-> owns resources
-> The resource owner wants to delegates his right to access a resource to a
third party application.