Update 11-authentication.livemd

Ready for review

Author: hvalkerie19

modules/11-authentication.livemd

@@ -26,7 +26,7 @@ Authentication is the mechanism that helps guard the front door of an applicatio
 
 ### Description
 
-Thinking back to the example above, authentication is establishing an entity is who they say they are.  For applications, this means, the user who is attempting to login, is the user who created and has control over the account.  But most applications have multiple levels of users, those with maxium access/privileges to move around and modify the application freely, and those with more restricted access. 
+Thinking back to the example above, authentication is establishing an entity is who they say they are.  For applications, this means, the user who is attempting to login, is the user who created and has control over the account.  But most applications have multiple levels of users, those with maximum access/privileges to move around and modify the application freely, and those with more restricted access. 
 
 Once an entity has been authenticated, then they are granted access but when implemented in an application/system, this often appears to happen in a single step. Users login and if you get a successful response you also get access to the application.  Access immediately follows Authentication, but how much access an entity is allowed and the actions they are permitted to, is authorized, to perform are governed by a set of permissions or access controls referred to as Authorization, which is often managed by a token or similar credentials. 
 
@@ -54,30 +54,37 @@ Authentication mechanism can be simple or complex.  Security industry best pract
 
 We mentioned earlier how both authorization (access) and sessions can be handled using tokens.  Access Tokens are built so that they contain information about what an authenticated user does and does not have access to, for how long, and they can also be used to manage the user's persistence/ongoing interactions with the application in a session.  
 
-Tokens are long strings of random characters used to identify an entity, session, as a badge for access and are usually generated by some token generating code, service or server.  In token-based implementations, at a highlevel the application or service generates tokens, assign token to users after they have been autenticated, check token validity as users access and use application functionality/features, and end/renew sessions by expiring and refresh tokens.
+Tokens are long strings of random characters used to identify an entity, session, as a badge for access and are usually generated by some token generating code, service or server.  In token-based implementations, at a highlevel the application or service generates tokens, assign token to users after they have been authenticated, check token validity as users access and use application functionality/features, and end/renew sessions by expiring and refresh tokens.
 
+### OAuth
+Open Authorization(OAuth) is a protocol in which a multi-step arrangement generates a token for a specific users, the user presents as a credential in lieu of a password. There is an extra server (authorization/token generating service or server) that after a user authenticates with it, it generates a token, and brokers authentication/authorization between initial entity and a resource.
 
+Originally built for authorization, as it's name suggests, it has evolved for use in the authentication and authorization mechanisms.  A very good resource that describes the OAuth in context of it's history and current implementations is here: https://www.youtube.com/watch?v=996OiexHze0
 
-Common implementations include OAuth: 
+Why use OAuth? When users need access to third party services, outside of your environment where you don't want to share your credentials with those third parties.  In OAuth protocol/architecture, an authorization service brokers access and grants users an access token to present, in place of credentials. 
 
-Open Authorization(OAuth) is a protocol in which a multi-step arrangement generates a token for a specific users, the user presents as a credential in lieu of a password.  Client-server model, there is an extra server (authorization/token generating service or server) that after a user authenticates with it, it generateds a token, and brokers authentication/authorization between initial entity and a resource.
+### <span style="color:blue;">Example</span> 
 
-Originally built for authorization, as it's name suggests, it has evolved for use in the authentication and authorization mechanisms.  A very good resource that describes the OAuth in context of it's history and current implementations is here: https://www.youtube.com/watch?v=996OiexHze0
+There are four primary entities involved with the OAuth protocol: requesting, service one, service 2, intermediary server that handles issuing tokens that get presented in lieu of credentials.  At a very high level, the flow looks something like
 
-JSON Web Tokens (abbreviated JWT, pronounced "jot")
-Multi-use tokens for authentication and session.  
-Three components, header contains information identifying type of token and algorithm used for the signature, payload/body that contains data about the disposition of the token, signature - which serves as an integrity check to establish if the token has been modified or tampered with. 
+-User Authenticated into Application/Service X
+-Application/Service X prompts user if they want to login using social media account credentials
+-User Logs into social media account/other service
+-Authorization Server/Service Generates Access Token 
+-Service X sends Token for limited access to Social Media Account (instead of sharing credentials)
 
-Base64 encoded and cryptographically signed
 
-Tokens, like other authentication credentials, etc. must be protected in transit and at rest. 
+``` 
+[OAuth2.Client module ](https://hexdocs.pm/oauth2/OAuth2.Client.html)
 
-Why use JWT? For post authentication authorization Can be signed and encrypted -> trust; low overhead; Integrity of information being transmitted and non-repudiation; JWT checkers validate token; token belongs to user
+```
 
-Expiration /Refresh
+### JWT
+JSON Web Tokens (abbreviated JWT, pronounced "jot") are multi-use tokens for authentication and session management.  JWTs have three components, header contains information identifying type of token and algorithm used for the signature, payload/body that contains data about the disposition of the token, signature - which serves as an integrity check to establish if the token has been modified or tampered with. 
 
-Why use OAuth? when Users need access to third party services, outside of your environment where you don't want to share your credentials with those third parties.  In OAuth protocol/architecture, an authorization service brokers access and grants users an access token to present, in place of credentials. 
+Tokens, like other authentication credentials, etc. must be protected in transit and at rest and can be Base64 encoded and cryptographically signed
 
+Why use JWT? For post authentication authorization, JWTs can be signed and encrypted which helps establish trust.  These tokens place little stress on the authentication and authorization mechanisms and help with implementing access controls throughout the application.
 
 ### <span style="color:blue;">Example</span> / <span style="color:red;">Quiz</span>
 
@@ -87,72 +94,40 @@ Create/Generate Token
 
 ```
 
-
-
-
 Validate Token
 ```
 def connect(%{"authorize" => token}, socket, _connect_info) do  //
   case JwtChecker.validate_token(token)do
   ...
   ...
 ```
-
+### References
 https://dev.to/onpointvn/implement-jwt-authentication-with-phoenix-token-n58
 (https://hexdocs.pm/guardian/Guardian.Token.Jwt.html)
-
 https://elixirschool.com/blog/jwt-auth-with-joken/
 
 
-
-### <span style="color:blue;">Example</span> / <span style="color:red;">Quiz</span>
-
-Oauth simple
-One of the concepts we'll discuss later, OAuth, a protocol originally designed for authorization, has evolved into providing  authentication as well (not intended).  
-
-User Authenticated into Application/Service X
-Application/Service X prompts user if they want to login using social media account credentials
-User Logs into social media account/other service
-Authorization Server/Service Generates Access Token 
-Service X sends Token for limited access to Social Media Account (instead of sharing credentials)
-
-https://www.youtube.com/watch?v=996OiexHze0
-
-Three primary entities, requesting, service one, service 2, intermediary server that handles issuing tokens that get presented in lieu of credentials
-
-``` 
-[OAuth2.Client module ](https://hexdocs.pm/oauth2/OAuth2.Client.html)
-
-```
-
 ## Sessions
 
 ### Description
 
-Authentication is the first step a user must complete to access a secure application/data.  For an application, that means something must be sent from 
-user->application authentication mechanism
-and from
-application authentication mechanism-> user - 
-
-Once an entity is authenticated, subsequent activity/interactions need to be tracked/attributed to the same entity.  This is done by 
-establishing and manage a Session. This allows a user, once authenticated to have access to the application without having to show their credentials every time they want to perform an action.
+Authentication is the first step a user must complete to access a secure application/data. Once an entity is authenticated, subsequent activity/interactions need to be tracked as belonging to the same entity.  
 
-Sessions save and keep updated the state of a user while the use an application.  Opening time and closing time at a museum.  A ticket and/or stamp gets you in and you can come and go in areas allowed by public/membership, but once the museum closes, you have to leave and come back another day.  If you have a membership or ticket for multiple visits, you have to show your card/ticket at the door again.
+Some applications do this by establishing and managing a session. Other applications are "session-less" and required a different approach for keeping the application's "knowledge" of what a user is doing while they use an application. 
 
-Sessions do something similar this for applications.  Depending on the application, however, they may be 
+For session-less applications, once a user authenticates, the server assigns and sends a token to their client.  For any following requests, the client sends their token in each request, like with JWTs discussed previously.  The server only checks the validity of the token.
 
-Session and Sessionless 
+In session oriented applications, one the user authenticates, information in subsequent requests are compared to session information kept on the server. 
 
-Session is being able to come and go so long as you're carrying your membership card. 
-
-Session-less ... fire and forget purchasing a single day pass for the museam.  You don't get a membership card with your name, and if you're paying cash, probably can't track you individually.
+In a way, this is like a museum visit. A session is like showing your membership card or ticket for the day.  Generally you can come and go on your day pass (they'll probably stamp you hand if you leave but you can get back in no problem).  Once the museum closes, the session is over and you have to leave and come back another day.  If you have a membership or ticket for multiple visits, you have to show your card/ticket at the door again.
 
+Session-less, sometimes referred to as "fire and forget it" is like purchasing a single day pass with cash.  Your name probably isn't in the system and if you come back a month later to buy another day pass, there's no record of you having been there previously.  (For simplicity we'll ignore any tracking.)  If you have a membership card with your name, however,  and if you're paying cash, probably can't track you individually.
 
 ## Authentication and Security Concerns
 
-An application's authentication mechanism is a critical component.  If not securely designed, it can provide an attack vector for malicious actors to gain access to legitimate user accounts, privileged application features, and 
+An application's authentication mechanism is a critical component.  If not securely designed, it can provide an attack vector for malicious actors to gain access to legitimate user accounts, privileged application features, and sensitive data. 
 
-Authentication, credentials, should never be stored in cleartext, hardcoded in code base, 
+-Authentication, credentials, should never be stored in cleartext, nore hardcoded in source code
 Credential Stuffing Attacks
 Security concerns/examples of multi-factor authentication getting hacked
 Multi-factor authentication (MFA) fatigue attack - aka MFA Bombing - aka MFA Spamming
@@ -163,37 +138,49 @@ Authentication Issues, Weaknesses, Failures make an appearance on multiple lists
 OWASP Top 10 for Web Applications A07:2021-Identification and Authentication Failurs (used to be called Broken Authenticication
 
 ## Prevention and Countermeasures
-Use built and tested authentication mechanisms in your code language framework.  Due to the complexity, it is 
+Use built and tested authentication mechanisms in your code language framework.  
 
-## Quiz
 Authentication is a key component of an application but given its integration with some of the other concepts mentioned in this module, it's implementation in your products can become complex. This module touched on some of the highlights but please refer to the references below for extensive explanations of authentication and related. 
 
-### <span style="color:blue;">Example</span> / <span style="color:red;">Quiz</span>
+### <span style="color:red;">Quiz</span>
 
+**Which of the following OWASP Top 10 Web Application Security Risks are related to the abuse of credentials or flaws in mult-factor authentication implementation?**
 
+*Uncomment the line with your answer*
 ```
-Which of the following OWASP Top 10 Web Application Security Risks are related to the abuse of credentials or flaws in mult-factor authentication implementation?
-1)A02:2021-Cryptographic Failures
-2)A05:2021-Security Misconfiguration
-3)A07:2021-Identification and Authentication Failures
-4)A08:2017-Insecure Deserialization
+
+# A02:2021-Cryptographic Failures
+# A05:2021-Security Misconfiguration
+# A07:2021-Identification and Authentication Failures
+# A08:2017-Insecure Deserialization
+
+IO.puts(answer)
 
 ```
 
+**Which two are examples of a credential that can be used in an application's authentication process?**
+
+*Uncomment the line with your answer*
+
 ```
-Which two are examples of a credential that can be used in an application's authentication process?
-1)token
-2)api call
-3)session
-4)username and password
+# token
+# api call
+# session
+# username and password
+
+IO.puts(answer)
 
 ```
+
+**Which statement best characterizes how an entity trying to be properly authenticated goes about it?**
+
 ```
-Which statement best characterizes how an entity trying to be properly authenticated goes about it?
-1)Hello, I just came from X street and would like to enter your establishment. I am who I say I am and I can show you proof.  May I enter?
-2)Let me in, now! Let me in , now! Let me in, now!!!!! 
-3)Trust me, I'm harmless
-4)Yes, I know that id doesn't look like me but my friend said I can use it so it's ok
+*Uncomment the line with your answer*
+
+# Hello, I just came from X street and would like to enter your establishment. I am who I say I am and I can show you proof.  May I enter?
+# Let me in, now! Let me in , now! Let me in, now!!!!! 
+# Trust me, I'm harmless
+# Yes, I know that id doesn't look like me but my friend said I can use it so it's ok
 
 ```