1. API Auth By Kyle Bradley

2. Role Definitions  User (Resource Owner)  The resource owner is the person who is giving access to some portion of their account.  Server/API (Resource Server)  The resource server is the API server used to access the user's information.  Client (Third-Party Application)  The client is the application that is attempting to get access to the user's account. It needs to get permission from the user before it can do so.

3. oAuth 2.0 Grant Types  Authorization Code  Apps running on web-server  Implicit Grant  Browser-Based  Mobile Apps  Password  Internal Username-Password  Client Credentials  Application Access

4. Authorization Type (Secure Server)  Client Request Auth from Server using Client Id  (User redirected to server to allow access)  Server returns an auth code to client  (User redirected to client)  Client sends to server:  Client Id  Client Secret  Auth Code  Server responds with access token.

5. Implicit Type (Brower, Apps)  Client requests token from server using Client Id  (Redirects user to server to allow access)  Server returns token

6. Password (Internal Username-Password)  (User request’s client username and password)  Client sends to server:  Client Id  Username  Password  Server responds with access token.

7. Client Credentials  (Client stores a client secret)  Client sends to server:  Client Id  Client Secret  Server responds with access token.

8. Two-Legged Auth  Client-Credentials  Implicit Grant  Password

9. Gateway Security  Apps are inherently vulnerable. (Reverse-Engineering)  Modify Current System  Implement “Client”  IsSafe property on client  Safe clients can use AppKey on all calls.  Non-Safe clients require a token to access pathing calls  Allows us to constrain on individual calls.  Overly oAuth (Recommend)  Implement “Client”  Allow Implicit Property (External clients will have to use client credentials)  Use Implicit grant type (Client Credentials on secure)  Client_ID is AppKey  Client Secret (Optional)  Constrain on temporary token (expirt/limited calls)  Token purely used for data analysis and as identifier within Fmw/Tct

10. Overly oAuth Cond.  Defaulted roles per call that can be assigned to clients  Basic (GET Paths call)  Moderate (GET Paths, announcements etc)  Internal (POST Coordinates etc)  Trusted (GET Timetables)

11. Clients  FindMyWay  TransportCapeTown  AppCampus  GauTrain*

12. Sources  oAuth Bible: Overly of oAuth in it’s entirety oAuth Bible:  oAuth Simplified: Different grating types and flow oAuth Simplified:  Apps aren’t secure #1: Own API to own iOS app Apps aren’t secure #1:  Apps aren’t secure #2: Never verify any entity. Only very what they telling you and then assume honesty. Apps aren’t secure #2:  Apps aren’t secure #3: Token system secure in web. App is vulnerable. Apps aren’t secure #3:  Securing OpenApi: Different methods and why use Implicit Grant Securing OpenApi: