Mobile Single Sign-On

The other day, we were at customer's site and the discussion was on Mobile Single Sign-On (MSSO). This customer will be launching a few mobile applications and he would like users to have the convenience of not having to sign-on every time a mobile application is launched.

Traditional Mobile Single Sign-On

The traditional method of achieving MSSO is to develop yet another mobile application to act as a SSO Wallet and the SSO Wallet will act as the bridge between the various mobile applications and the Identity Provider (IdP). 

I'm using Gluu Server as an example now. But IdP can be any federation solution. 

Modern Mobile Single Sign-On

In iOS and Android, simple MSSO solutions are provided by tapping on the Cookie concept in browser.

For iOS, SFSafariViewController is recommended, while in Android, Chrome Custom Tabs is suggested. 

Quite convenient to implement.

Of course, we did discuss about a scenario whereby Chrome browser is not installed, then MSSO on Android will fail. This can be overcome by user education.


.

Client Credential Grant Type and Refresh Token

I was in a discussion with a customer today and we talked about how to reduce the number of calls to Kong API Gateway.

This particular API Gateway is only for internal applications communication, thus Client Credential Grant is configured on each endpoint.

The main concern was that prior to each endpoint call, the internal applications have to make a call to request for a OAuth2 access token. This will be 2 calls to the Kong API Gateway per endpoint.

But, hey, if this is a setup of internal applications communication, we can increase the access token timeout. And it is programming best practice to reuse established access token, rather than to get a new access token prior to each endpoint call.

There's a choice.

The APIs are not exposed to the public. If the application teams within the same company cannot cooperate with one another, there's nothing we can do about it.


The customer continued to probe further: "Can't we ask the application team to use the OAuth2 refresh token to exchange for a new OAuth2 access token?"

But... this is Client Credential Grant type. There's no refresh token generated.

Refresh tokens are only provided when retrieving a token using the Authorization Code or User Credentials grant types.


.

Tomcat container log file is filling up with messages from OpenAM's OAuth authorization service

I was browsing through OpenAM 12 documentation and came across the Troubleshooting section.

There is this particular FAQ that caught my attention.

Q: My container log file is filling up with messages from OpenAM's OAuth authorization service and OpenID Connect provider. What can I do to prevent all these messages from being logged?

I shall paste the answer shamelessly from the OpenAM documentation.

A:

This behavior is governed by the log settings for RESTlet, which is used by OpenAM for OAuth 2.0 and OpenID Connect 1.0. Use log configuration settings to turn off logging from RESTlet.

For example, if your container is Apache Tomcat, follow these steps.

1. Stop Tomcat.

$ /path/to/tomcat/bin/shutdown.sh

       

2. Edit the Tomcat settings script, catalina.sh or catalina.bat, to use the logging configuration file.

For example, in /path/to/tomcat/bin/catalina.sh, uncomment the following line, and then save your work:

LOGGING_CONFIG= \

  "-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties"

3. In $CATALINA_BASE/conf/logging.properties, add the following line, and then save your work:

org.restlet.level=OFF

       

4. Start Tomcat.

$ /path/to/tomcat/bin/startup.sh

I have seen these logs in catalina.out in my customer's Tomcat servers, but did not find the time to find out why they appear there. This solves the mystery. :)

.