DPS907 notes – Thu Nov 12

Security topics.

 

Discussion – client app

Your professor will discuss and demonstrate a client app.

Get the three projects in the Week 9 folder of the GitHub code repository.

IdentityServerV2: You have used this before, and you know what it is.

SolutionForLab7: This is a sample solution, created by your professor.

ClientAppInstruments: An ASP.NET MVC web app.

Note the following about ClientAppInstruments:

  • It does NOT include the ASP.NET Identity security components
  • It sends requests to the Lab 7 sample solution web service
  • The web service is secured, and relies on tokens issued by the identity authority
  • As a result, the client app includes a login page which obtains a token from the identity authority

 

Study its code, and use the app. Start the three apps named above, in the named sequence above.

web-service-as-a-resource-server-v3

 

Discussion – OAuth scenarios

At this point in time, you should have read or skimmed the Security on the web document.

It defines client apps and flows. From the document:

~~~~~~~~~~

There are two defined types of client apps:

  1. Confidential – Capable of maintaining confidentiality of client app credentials. Includes server-based web apps and services. Also includes mobile device (e.g. iPhone) apps that are trusted by the device owner.
  2. Public – Not capable of maintaining confidentiality of client app credentials. Includes JavaScript apps and modules.

There are four defined flows or scenarios that enable a resource owner to authorize the issuance of an access token:

  1. Authorization code – A resource owner is able to authenticate directly with an authorization server, and passes on an “authorization code” to the client app.
  2. Implicit – For client apps which are implemented in a browser using a scripting language (such as JavaScript).
  3. Resource owner password credentials – Where there is a high degree of trust between the resource owner and the client app (e.g. a trusted client app on a resource owner’s trusted mobile device).
  4. Client credentials – For access to protected resources that are under the control of the client app (and not to any specific/individual resource owner).

Examples:

  1. Authorization code – Browser, with a “web app” as a client (app)
  2. Implicit – Browser (or ‘web view’ object in a native app), with a non-confidential client (app), typically in JavaScript
  3. Resource owner password credentials – Trusted device, with a trusted client (app), typically on iOS and Android mobile devices
  4. Client credentials – A human is not directly involved; could be a component in one of the client (apps) above (e.g. sync, UI assets, etc.)

 

~~~~~~~~~~

 

Most of our work has been based on the resource owner password credentials flow. Fiddler is running on a trusted device (your computer), and interacting with a resource server and identity authority that trust each other.

Today’s three-project code example also simulates this flow, by embedding a login page into the app. The implication is that the human user of the browser trusts the client app, and the client app is trusted by the identity authority. (That’s an important factor.)

Next week, we will look at an example that uses the “authorization code” flow. In that situation, the client app is NOT trusted by the identity authority (e.g. Facebook or Google). Instead, it “allows” the client app to redirect the user to the identity authority for authentication. It will then return a token to the client app. The resource server trusts tokens issued by the identity authority, so it all works well.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Advertisements
%d bloggers like this: