SignIn Widget and scopes

Questions
1

Hi. I am now in the process of upgrading our Okta dependencies. We are going from okta-angular 1.4.0 to okta-angular 3.0.1 and from okta-signin-widget 3.3.0 to okta-sign-in-widget 5.0.0 We are using the implicit flow, We are using the sign in widget and then using a redirect component which uses the OktaAuthService to read the tokens from the redirect and set up authorization. We need to be receiving the groups scope in the token, and our current version does; our authorization server is configured to send it. The configuration object for the signIn widget looks like this:
authParams {
display: “page”
issuer: “https://XXXXXXXXXXXXXXXXXXXXXXXXXXX/oauth2/default”
pkce: false
responseType: “id_token”
scopes: [“openid”, “profile”, “email”, “groups”]
}

baseUrl: "XXXXXXXXXXXXXXXXXXXXXXXXXXXX"
clientId: "XXXXXXXXXXXXXXX"
features: {
	showPasswordToggleOnSignInPage: true
}

helpLinks: {
	help: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}
i18n: {en: {…}}
idpDisplay: "SECONDARY"
idps: (2) [{…}, {…}]
logo: "/assets/images/logo.svg"
redirectUri: "XXXXXXXXXXXXXX/callback"

For some reason, the scopes I’m setting on the authParams is being overwriiten to [‘openid’, ‘email’], so that is the only data I’m getting back. I need the groups and profile data. How do I make it request this data? The old versions have no problems getting this data.

Ted

2

I’ve found the answer, and thought I’d share.

Within our LoginComponent, we were calling signIn.renderEl For the upgrade, I replaced it with signIn.showSignInAndRedirect() and assumed without checking that it took the same parameters as renderEl. It can take an options object. Undocumented, the options object can have a scopes property, a string array of the scopes to be requested. Even worse, and also undocumented, is that if no scopes property is passed, it defaults not to the scopes property passed to the constructor, but to ['openid', 'email'].

3

Hey! I’m glad you were able to get it working as it looks like you ran into a bug with the underlying Auth JS SDK that was fixed in version 4.1.1 and 4.0.4. With a widget bundled with either version of AuthJS, you should only need to set it in the constructor and not redundantly.

I’m told that we will be updating this in this week’s widget release, so you can check out the fix once that’s out.

4

Andrea,

I’ve updated to v. 5.0.2. Doesn’t appear to have fixed it. To be clear, we’re using signIn.showSignInAndRedirect() not signIn. showSignInToGetTokens() The docs for signIn.showSignInAndRedirect() still don’t indicate you can pass scopes as part of the options object.