Applications need to be protected against the OWASP Top 10 vulnerabilities. This is a challenge for most enterprises and usually leads to breaches if not implemented in a standardized fashion. In Part 1 of this blog we will first describe the types of Access Management implementations, different types of applications (clients in OAuth speak) and the associated vulnerabilities. Part 2, we will detail the different types of OAuth 2.0 Grant types. These types are used to obtain security tokens which will be used by clients to interact with the back-end systems. Part 3 of this blog will detail recommend security controls. We will also speak about how to protect your security tokens (i.e., bearer token) at rest and inflight.

We will show how the IAM stack plays a crucial role in your implementation. Besides identity is the  ‘HUB” in your hub and spoke security implementation model. Remember app developers need not worry about coding security in on stubs or methods. They need to just use a standardized and repeatable framework via APIs or other means.


Access Management implementation types

Your applications can be secured and integrated with an IAM stack via the traditional Web Access Management (WAM), OAuth 2.0 (incl. OIDC) or both, the latter being the most interesting.

WAM: WAM is an access management architecture based on reverse proxy setup where agents are installed on a proxy farm (a group of web servers) to intercept HTTP requests to the backend for authentication and authorization. This allows a central Policy Definition Point (PDP) where global and specific rules are configured and effected inflight across all of an enterprise sites. This is useful when session management is critical and should be maintained via a global overarching single session stored centrally. The central WAM module has configurable policies that can share identity data via http headers, session and identity assertions.

OAuth 2.0: Open-authorization 2.0 is a token based authentication and authorization framework.  It enables a federated integration where enterprise applications are the Relying Party (RP) that receive identity and authentication and authorization status data (in tokens). The authorization server is the Identity Provider (IDP). The process to obtain  is driven by different OAuth 2.0 Grants that can be 2-legged or 3-legged in nature depending on requirements. The identity and security context is shared between participants by way of tokens and tickets. The tokens can be self-contained or not in which case the authorization server (AS) will have to validate these tokens when they are used to call backend assets for data and transactions. This validation process is commonly referred to as introspection.


Types of Applications / Clients

WAM Clients

Client: An  end-user uses various devices to access a web application. These devices make use of a “trusted agent” installed on them. The trusted agent being a web browser. The browser interacts with the back-end web application to retrieve and render remote content. Thus the browser is therefore the client. The web applications are typically built using different pages and an end-user clicks on buttons and links to navigate to each page. This makes it simple for a WAM based SSO integration to work efficiently as each button pressed is a resource request and usually creates an http request and response that can be intercepted by a WAM SSO agent for security. Even in Single Page Applications (SPAs) architectures, the SPA requests have to routed via an WAM SSO agent. We will talk about in later blogs.

OAuth 2.0

  • Client: An authorized application making protected resource requests on behalf of the resource owner. The term client is not specific to a particular entity, for example the client could be an application that executes on a server, computer or mobile device. The OAuth 2.0 specification defines two types of clients:


    • Confidential
    • Public


High level details about WAM


WAM clients are usually http stateful architectures. We simply manage security by way of sessions and cookies. The cookies are client side tokens that are used to correlate session state with the backend stored session. Typically this configuration contains a proxy between the client and the bank-end for various reasons including an agent that intercepts the requests and queries the WAM access management module for validity.

Example: WAM Client

Here is an illustration of a WAM architecture (MPA or SPA) where sessions are correlated using cookies:


WAM Security Threats

  • Man-in-the-browser attack
  • Session Hijacking
  • Cookie tampering

For a comprehensive list of vulnerabilities, Please contact us.


This section speaks about Oauth clients and associated profiles


OAuth Clients

  • A confidential client is an application that is capable of keeping a client’s client ID and secret (also referred to as API keys) confidential to the world. These credentials are assigned to the client application by the authorization server via a registration process which can be offline (i.e., administrator configuring the client in admin console) or online (during first login). These credentials are used to identify and authenticate the client to the authorization server. An example of a confidential client could be a web application where no one but the administrator can get access to the server, and see the client’s credentials.
  • A public client is an application that is not capable of keeping its credentials confidential. For instance, a mobile phone application or a desktop application that has the credentials embedded inside it. Such an application could get cracked, and this could reveal the credentials. The same is true for a JavaScript application running in the user’s browser. The user could use a JavaScript debugger to look into the application, and see the credentials.


OAuth Client Profiles

The OAuth 2.0 specification also mentions a set of client profiles. These profiles are concrete types of applications that can either be confidential or public. The profiles are:

    • Web application
    • User Agent application
    • Native application


Web Application


  • Web Application


A web application is an application running on a web server. A web application typically consists of both a browser and a server. In OAuth, when a web application needs access to a Resource Server (e.g. Back end API), then the client ID and secret (API keys) could be stored server side. These credentials are thus seen to be confidential. Clients are registered with the OAuth service and the credentials are created and shared at registration time.

In this type of profile, Resource Owners access the OAuth client via an HTML user interface rendered in a user-agent (browser) on the device used by the Resource Owner. The OAuth client credentials as well as any security tokens issued to the client are stored on the web server and are not exposed to or accessible by the Resource Owner. That is, they are not stored on the browser.


Example: Confidential Web Client

Here is an illustration of a confidential client- Multipage web application:


User Agent Application


  • User Agent Application


A user-agent-based application is a public OAuth client in which the OAuth client code is downloaded from a web server and executes within a user-agent (e.g., web browser) on the device used by the Resource Owner. Protocol data and credentials are easily accessible (and often visible) to the Resource Owner. Since such applications reside within the user-agent, they can make seamless use of the user-agent capabilities when requesting authorization.

These types of clients use advanced JavaScript frameworks to interact with the back-end to request resources. These frameworks include AJAX, Angular and so forth. Security vulnerabilities are heightened in these applications due to their nature.


Example: User Agent Application

Here is an illustration of a client user agent application: Single Page Application (SPA)


Native Applications

  • Native Application


A native application is typically an OAuth Public client installed and executed on the device used by the Resource Owner. Protocol data and credentials are accessible to the Resource Owner. It is assumed that any client authentication credentials included in the application can be extracted, therefore credentials should NEVER be stored in these kinds of clients. On the other hand, dynamically issued credentials such as security tokens (bearer token) can receive an acceptable level of protection which we will discuss in Part 3 of this blog.

Dynamic credentials should also be protected from other applications residing on the same mobile device.


Example: Native Applications

Here is an illustration of a native client application: mobile app


Hybrid Applications


  • Hybrid Applications


Some applications are hybrids of the above. For instance, a native application can have a server part too, that does part of the work (e.g. store data. In most cases a hybrid client will be able to use the authentication models of one of these profiles.


OAuth Security Threats

  • Security Threats


The threats listed below are derived from IETF RFC6819 OAuth 2.0 Threat Model and Security Considerations. This thread model for OAuth clients are categorized as follows:


OAuth Security Threats


ID Threat Client Type Description
1 Cross-Site Scripting (XSS) Public (Single Page Apps making use of localStorage   or sessionStorage to store valuable information such as bearer tokens, client id and secret [API Keys])

XSS is the ability for an attacker to run JavaScript on your website and extracting valuable information. This information is then sent to the attacker’s domain for use or used within your websites without knowledge.

LocalStorage and SessionStorage are not secure to store critical information.

2 Cross-Site Request Forgery (CSRF) Public (Sites that store valuable information to store valuable information such as bearer tokens, client id and secret [API keys] in insecure cookies) Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.


For a comprehensive list of OAuth and SAML vulnerabilities, Please contact us.