I spent parts of 2013 to 2015 working on OAuth2 servers at Stanford and Jive Software. Below are a bunch of the questions that come up internally as part of a roll out or on boarding new applications. In particular defining scopes can be tricky since they can be very domain specific.
I'm interested in OAuth2 things.
Is your campus using OAuth2 to protect APIs?
Are you using scopes to control access to those APIs?
If so, what scopes have you defined and how are they used? Example: a white pages API might define scopes of 'public', 'institution' and 'private', which would correspond with the access rights needed to see a attributes that were marked public, institution only, or private.
If so, how do you control which users or apps can authorize which scopes?
How long do you issue access tokens for? Does lifetime depend on scope?
How long are refresh tokens good for? Can you continually refresh for a new refresh token?
What is your process for registering new apps/Oauth2 clients?
Token revocations
Do you revoke any tokens when a user's account is deactivated?
How do resource servers/APIs know about revoked tokens? via token introspection? event notification?
What tool or SDK is your resource server/API using to validate tokens?
Do you support rotating the signing key used by the Authorization server?
Thank you Patrick. It sounds like your concern is primarily around using OAuth2 token as an authn/authz mechanism for API access. Who do these tokens typically belong to/assigned to? Are they issued for the application calling the API, or are they issued for the person accessing the application calling the API?
It depends on the use case and the type of app. A backend system that needs to call an API would use the 'Client Credential Grant' flow of OAuth2 and likely be the 'subject' of the token. A mobile app, in contrast, is considered a public client (since it can't keep a credential confidential) and would rely on a user consenting/authorizing for a token to be generated. In this case the token has the person as the subject.
The Oauth2 core specs only defines the interaction between the client and the authorization server, and the client and the resource server, and leaves everything as an implementation decision. This gives you a lot of ways to make incompatible, and/or bad decisions. I've found using a JWT (hence my reference to 'subject') as the token format is the most common way of ensuring some level of basic compatibility across libraries, languages and frameworks.
Thank you Patrick. If you have a few moments, could you review a couple of videos I found on Youtube and comment on whether they fairly represent their respect topics? I am trying to compile a series of lay person friendly explanations of this topic. I am anticipating that the survey respondents will largely not be as well versed in the details of the protocols as you and other IDM experts. I am thinking that we will need a way to introduce the topic and questions in a way an average developer or IT manager can intuitively understand.
For example, while I understand what you mean, and I have been involved in the IDM field for 15 years now, I find myself having to do a whole lot of reading and mental mapping/translation when discussing this subject. I am concerned that if the average respondent shares my pain, we are not going to get a lot of quality responses simply because the investment to understand the questions is too high...
I thought the first one was quite good at touching on various parts of OAuth2, OIDC and JWTs without bogging down in detail. I do wish he mentioned which scopes and profile attributes were OIDC vs arbitrarly made up (voucher scope, and 'can buy in bulk' role) for the demo. The 2nd one I'm mixed on. The lesson is quite an important one but the recommendation is dated - both iOS 9+ and Android offer a 3rd mobile web options (Safari Web Views and Chrome Custom Tabs) that have the desired security controls and offer a better experience to popping the system browser. Also, with the heavy salesforce branding I'm not sure if someone would think "But I'm not integrating with salesforce" and stop watching before the lesson.
I agree with your concern about overwhelming the respondents. Maybe there are two broad categories of questions, with different intended audiences? For example asking about key factors, motivations, policy and use cases doesn't require in-depth knowledge of the protocols and implementation, but will help school gauge where they are on the adoption curve and what the next step is in the path forward. Once they start on the implementation side the OAuth2 service implementer is faced with a fairly blank canvas, and may want to know what other schools decided in regards to the more implementer specific/technical questions.
11 Comments
user-c1a6f
I would like to find out how organizations are integrating or plan to integrate OpenID Connect/OAuth 2 support with their single sign-on service.
user-c1a6f
I would like to find out who is currently working with OIDC and is willing to share their implementation as a case study.
user-c1a6f
I would like to find out what are the key factors driving a campus to investigate OIDC/OAuth support...
user-c1a6f
Does anyone have experience with https://keycloak.org?
Patrick Radtke (cirrusidentity.com)
We have two prospective customers in higher ed that use keycloak. Once we know what to ask, I can forward them the questions.
Patrick Radtke (cirrusidentity.com)
user-c1a6f
Thank you Patrick. It sounds like your concern is primarily around using OAuth2 token as an authn/authz mechanism for API access. Who do these tokens typically belong to/assigned to? Are they issued for the application calling the API, or are they issued for the person accessing the application calling the API?
Patrick Radtke (cirrusidentity.com)
It depends on the use case and the type of app. A backend system that needs to call an API would use the 'Client Credential Grant' flow of OAuth2 and likely be the 'subject' of the token. A mobile app, in contrast, is considered a public client (since it can't keep a credential confidential) and would rely on a user consenting/authorizing for a token to be generated. In this case the token has the person as the subject.
The Oauth2 core specs only defines the interaction between the client and the authorization server, and the client and the resource server, and leaves everything as an implementation decision. This gives you a lot of ways to make incompatible, and/or bad decisions. I've found using a JWT (hence my reference to 'subject') as the token format is the most common way of ensuring some level of basic compatibility across libraries, languages and frameworks.
user-c1a6f
Thank you Patrick. If you have a few moments, could you review a couple of videos I found on Youtube and comment on whether they fairly represent their respect topics? I am trying to compile a series of lay person friendly explanations of this topic. I am anticipating that the survey respondents will largely not be as well versed in the details of the protocols as you and other IDM experts. I am thinking that we will need a way to introduce the topic and questions in a way an average developer or IT manager can intuitively understand.
For example, while I understand what you mean, and I have been involved in the IDM field for 15 years now, I find myself having to do a whole lot of reading and mental mapping/translation when discussing this subject. I am concerned that if the average respondent shares my pain, we are not going to get a lot of quality responses simply because the investment to understand the questions is too high...
Patrick Radtke (cirrusidentity.com)
I thought the first one was quite good at touching on various parts of OAuth2, OIDC and JWTs without bogging down in detail. I do wish he mentioned which scopes and profile attributes were OIDC vs arbitrarly made up (voucher scope, and 'can buy in bulk' role) for the demo. The 2nd one I'm mixed on. The lesson is quite an important one but the recommendation is dated - both iOS 9+ and Android offer a 3rd mobile web options (Safari Web Views and Chrome Custom Tabs) that have the desired security controls and offer a better experience to popping the system browser. Also, with the heavy salesforce branding I'm not sure if someone would think "But I'm not integrating with salesforce" and stop watching before the lesson.
I agree with your concern about overwhelming the respondents. Maybe there are two broad categories of questions, with different intended audiences? For example asking about key factors, motivations, policy and use cases doesn't require in-depth knowledge of the protocols and implementation, but will help school gauge where they are on the adoption curve and what the next step is in the path forward. Once they start on the implementation side the OAuth2 service implementer is faced with a fairly blank canvas, and may want to know what other schools decided in regards to the more implementer specific/technical questions.
Patrick Radtke (cirrusidentity.com)
Policy around who can register OIDC/Oauth2 clients?
Are mobile apps allowed to use embedded web views for sign-in? Embedded web views allow the app to see any submitted credential.