I might be loosing something in the configuration as with okta I also have problems in order to acquire access token from authorization code. I'm attaching captures of errors and config: https://www.dropbox.com/s/6msy6zy4bbjv9p0/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-20%2021-22-55.png?dl=0 https://www.dropbox.com/s/96ikumco91rhix8/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-20%2021-23-23.png?dl=0 https://www.dropbox.com/s/escs759rt5s5r73/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-20%2021-23-30.png?dl=0 https://www.dropbox.com/s/epsjwiqcatjcffl/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-20%2021-24-45.png?dl=0 https://www.dropbox.com/s/fclqxj2wudjzn2l/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-20%2021-24-52.png?dl=0 https://www.dropbox.com/s/vyd1e7ez3ebgiy0/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-20%2021-25-01.png?dl=0

Hi, Vreixo Luis Gonzalez. We will need a bit more data to figure out this. 1. In oxTrust, move to "Configuration" > "JSON Configuration" > "oxAuth configuration" and set `logginLevel" parameter there to "TRACE" 2. Move to "OpenID Connect" > "Clients", open the client you registered there for Moodle (or find the one that was registered dynamically for it), and open it; click "Client config summary" button there and share result with us 3. Record a network trace of your full flow with Moodle, export it as HAR file and share with us; you can use steps listed [here](https://www.inflectra.com/support/knowledgebase/kb254.aspx) - please use Firefox for that task, Chrome's HARs are flawed. Also don't forget to set "Persist log" and "Disable cache" checkboxes in the console to save everything, not just the recently loaded page 4. After exporting the HAR file, fetch the current `/opt/gluu/jetty/oxauth/logs/oxauth.log` file from inside "oxauth" container, and upload it as well; we need it to be harvested after the HAR file, as it need to contain entries related to this network trace Could you also elaborate on that part? >The problem is that any user details are transferred to Moodle. I have tested with option to return JWT for accesstoken but I have the same result. Is there any place where to configure what will actually be present in the token? In Keycloak there is a whole section for token mapping for example but I didn't find anything similar in oxtrust. Do you mean you don't receive user's claims you expect to be present? Could you describe what you try to achieve (what is an expected behavior, in your opinion)?

Sure, I'm attaching the extra information, for all the configured clients that I have tested, the two playground and Moodle and Okta which are the integrations that we want to have in place. I have cropped logs to make it easier but I'm attaching also full logs just in case. Regarding Moodle integration, from these more detailed logs I'm seeing that a JWT token is issued but just not with all the claims that I would like, the issue is that I didn't find the place were to define claims to be present in the token. In relation with Okta I don't know where is the issue but it seems to not work at all as with the playgrounds. I have added them as I found it strange that they didn't work as openidconnect.net worked perfectly with Keycloak with a configuration out of the box, but the more important for us is Okta and Moodle which are two services that we want to use. Thank you very much in advance, Moodle: 2. Here is the summary: OPENID CONNECT CLIENTS DETAILS ------------------------------ - **Name:** Edunao - **Client ID:** 3afb749b-b37a-4469-bc3b-f43e10ddf629 - **Subject Type:** pairwise - **ClientSecret:** XXXXXXXXXXX - **Application Type:** web - **Persist Client Authorizations:** true - **Pre-Authorization:** true - **Authentication method for the Token Endpoint:** client_secret_post - **Logout Session Required:** true - **Include Claims In Id Token:** false - **Disabled:** false - **Login Redirect URIs:** [https://whispeak.edunao.com/auth/oidc/] - **Scopes:** [profile, openid, email, user_name, address, permission, phone] - **Grant types:** [authorization_code, implicit, refresh_token, password, client_credentials] - **Response types:** [code, token, id_token] 3. HAR file: [ https://www.dropbox.com/s/c3klccgcqjuv73p/whispeak-moodle.har?dl=0 ](https://www.dropbox.com/s/c3klccgcqjuv73p/whispeak-moodle.har?dl=0) 4. Logs: [https://www.dropbox.com/s/lg8s7xlye30mopa/oxauth.log?dl=0 ](https://www.dropbox.com/s/lg8s7xlye30mopa/oxauth.log?dl=0) 5. Token with just username: { "aud": "3afb749b-b37a-4469-bc3b-f43e10ddf629", "sub": "Q2YgaLDzrBAQ-g6L5P4l-Vw0BBNXlOe93o5oMag11iQ", "x5t#S256": "", "code": "43db691f-efd3-4017-b367-0e7193e393f9", "scope": [ "openid", "profile", "email" ], "iss": "https://gluu.pre.whispeak.io", "token_type": "bearer", "exp": 1621550221, "iat": 1621549921, "client_id": "3afb749b-b37a-4469-bc3b-f43e10ddf629", "username": "testedunao2" } Okta: 2. Here is the summary: OPENID CONNECT CLIENTS DETAILS ------------------------------ - **Name:** OktaOIN - **Client ID:** 2c3aa794-c43f-4c4d-a15b-9266a95a0452 - **Subject Type:** pairwise - **ClientSecret:** XXXXXXXXXXX - **Application Type:** web - **Persist Client Authorizations:** true - **Pre-Authorization:** true - **Authentication method for the Token Endpoint:** client_secret_post - **Logout Session Required:** false - **Include Claims In Id Token:** false - **Disabled:** false - **Login Redirect URIs:** [https://dev-05893753.okta.com/oauth2/v1/authorize/callback] - **Scopes:** [profile, openid, permission, phone, address, mobile_phone, email, user_name] - **Grant types:** [authorization_code, implicit, refresh_token, client_credentials, password] - **Response types:** [code, token, id_token] 3. HAR file: [https://www.dropbox.com/s/jqdvj66pls7mquv/whispeak-okta.har?dl=0 ](https://www.dropbox.com/s/jqdvj66pls7mquv/whispeak-okta.har?dl=0) 4. Logs: [https://www.dropbox.com/s/81ddxifasxaj8j7/oxauth-okta.log?dl=0 ](https://www.dropbox.com/s/81ddxifasxaj8j7/oxauth-okta.log?dl=0) Openidconnect.net: 2. Here is the summary: OPENID CONNECT CLIENTS DETAILS ------------------------------ - **Name:** Openidconnect - **Client ID:** b268c854-a7f6-48f5-9080-0a204b725245 - **Subject Type:** pairwise - **ClientSecret:** XXXXXXXXXXX - **Application Type:** web - **Persist Client Authorizations:** true - **Pre-Authorization:** true - **Authentication method for the Token Endpoint:** client_secret_post - **Logout Session Required:** true - **Include Claims In Id Token:** false - **Disabled:** false - **Login Redirect URIs:** [https://openidconnect.net/callback] - **Scopes:** [profile, openid, permission, phone, email, user_name] - **Grant types:** [authorization_code, implicit, refresh_token, password] - **Response types:** [code, token, id_token] 3. HAR file: [https://www.dropbox.com/s/glzvrv2l9gk5v6c/whispeak-openidconnect.har?dl=0 ](https://www.dropbox.com/s/glzvrv2l9gk5v6c/whispeak-openidconnect.har?dl=0) 4. Logs: [https://www.dropbox.com/s/qef5qwv1ypxnux0/oxauth-openidconnectnet.log?dl=0 ](https://www.dropbox.com/s/qef5qwv1ypxnux0/oxauth-openidconnectnet.log?dl=0) Akamai: 2. Here is the summary: OPENID CONNECT CLIENTS DETAILS ------------------------------ - **Name:** Akamai - **Client ID:** 2185671e-0094-476e-9726-50084cb7b764 - **Subject Type:** pairwise - **ClientSecret:** XXXXXXXXXXX - **Application Type:** web - **Persist Client Authorizations:** true - **Pre-Authorization:** true - **Authentication method for the Token Endpoint:** client_secret_post - **Logout Session Required:** true - **Include Claims In Id Token:** false - **Disabled:** false - **Login Redirect URIs:** [https://oidc-playground.akamai.com/redirect_uri] - **Scopes:** [profile, openid, permission, phone, address, email, user_name] - **Grant types:** [authorization_code, implicit, refresh_token, password, client_credentials, urn:ietf:params:oauth:grant-type:uma-ticket] - **Response types:** [code, token, id_token] 3. HAR file: [https://www.dropbox.com/s/gevjbp4mcwrmex7/whispeak-akamai.har?dl=0 ](https://www.dropbox.com/s/gevjbp4mcwrmex7/whispeak-akamai.har?dl=0) 4. Logs: [https://www.dropbox.com/s/beesecwonjov6nk/oxauth-akamai.log?dl=0 ](https://www.dropbox.com/s/beesecwonjov6nk/oxauth-akamai.log?dl=0) **Full Logs** [https://www.dropbox.com/s/tb4xmj9tnohirri/oxauth-full.log?dl=0](https://www.dropbox.com/s/tb4xmj9tnohirri/oxauth-full.log?dl=0)

>Regarding Moodle integration, from these more detailed logs I'm seeing that a JWT token is issued but just not with all the claims that I would like, the issue is that I didn't find the place were to define claims to be present in the token. What do you mean by "JWT token"? Normally, there could be two: id_token, and access token (if "access token as JWT" feature is enabled, which usually shouldn't be as it's intended for very specific purposes, not a regular OIDC flow). Even assuming it's `id_token`, it's still not common to pass user's attribute in it (though possible in Gluu). Normally, RP should use access token to pull user's claim from `/userinfo` endpoint. If you really have to pass the claims in `id_token`, you have to go to "Configuration" > "JSON Configuration" > "oxAuth configuration" again, find "legacyIdTokenClaims" parameter there and set it to "True" (don't forget to click "Update" button at the bottom). Then you also need to go to "OpenID Connect" > "Clients", open your Moodle client and make sure "Include Claims In Id Token" feature is enabled for it ("Advanced settings" tab).

Sorry if I missed it somewhere above, but could you also share screenshot of your current Moodle's configuration for Gluu you added while following the doc you mentioned in the first post?

> What do you mean by "JWT token"? Normally, there could be two: id_token, and access token (if "access token as JWT" feature is enabled, which usually shouldn't be as it's intended for very specific purposes, not a regular OIDC flow). Ok so I see that it's a configuration issue then. Well I'm used to work with id_tokens directly as JWT so in the front-end there is direct access to claims, I don't know if Moodle is going to do the call to "/userinfo", so if it's not the case I'll add the claims to id_token as you described. Regarding this endpoint of "/userinfo", it will return all claims exisiting for the user or just some of them? > Sorry if I missed it somewhere above, but could you also share screenshot of your current Moodle's configuration for Gluu you added while following the doc you mentioned in the first post? Well it was in the previous post as exported with the instructions that you told me but I'll attach to be easier to find with screenshot too: With interface copy button: OPENID CONNECT CLIENTS DETAILS ------------------------------ - **Name:** Edunao - **Client ID:** 3afb749b-b37a-4469-bc3b-f43e10ddf629 - **Subject Type:** pairwise - **ClientSecret:** XXXXXXXXXXX - **Application Type:** web - **Persist Client Authorizations:** true - **Pre-Authorization:** true - **Authentication method for the Token Endpoint:** client_secret_post - **Logout Session Required:** true - **Include Claims In Id Token:** false - **Disabled:** false - **Login Redirect URIs:** [https://whispeak.edunao.com/auth/oidc/] - **Scopes:** [profile, openid, email, user_name, address, permission, phone] - **Grant types:** [authorization_code, implicit, refresh_token, password, client_credentials] - **Response types:** [code, token, id_token] https://www.dropbox.com/s/g4v7ufl0tfyg2zk/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-21%2014-14-39.png?dl=0 https://www.dropbox.com/s/eqepzcvkomaauq9/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-21%2014-14-32.png?dl=0

Regarding the other integrations, I think that is more an error in the configuration that is breaking the flow. Did you checked the issues with Okta? The playgrounds were just for debugging the issue so not so important. Thanks in advance,

>Regarding this endpoint of "/userinfo", it will return all claims exisiting for the user or just some of them? That depends on what your client/RP requests from your Gluu Server (which scopes it sends in "scope=" url query parameter initially) - and what scopes your Gluu Server is ready to allow for this client as well (defined in its registration entry). So, for example, in your HAR file for Akamai I see that only "openid" scope is requested - so Gluu Server won't release any claims at all, except "sub" claim, despite in Gluu Server you have a long list of scopes allowed for this client: `profile, openid, permission, phone, address, email, user_name` Yet, it doesn't seem to be the main issue with this particular flow, as it fails later when querying `/token` endpoint, for some reason (still not clear to me).

>Well it was in the previous post as exported with the instructions that you told me but I'll attach to be easier to find with screenshot too: Sorry, I probably wasn't clear enough: I meant the configuration on Moodle's side, not the client's properties from Gluu. In the [original doc](https://gluu.org/docs/gluu-server/4.2/integration/saas/moodle/), at the end of it, there is part: "Configure Gluu in Moodle." Could you show me what is currently there?

I don't see any errors in your Moodle's HAR, so it seems like at least the OIDC flow itself succeeds. So, the issue is that you still don't see some user's attributes passed to Moodle? Correct? If so, which ones? Currently I see that Moodle requests for "openid", "email" and "profile" scopes, that should result in a fair share of personal claims (you can see which claims each scope covers on "OpenID Connect" > "Scopes" page). So you could probably made Moodle to request more scopes (and add the to Moodle's client entry in Gluu Server).

>Did you checked the issues with Okta? Still in process. The problem here is that it uses a regular code flow, so HAR won't show what happens next after flow is sent back to Okta's callback endpoint with authorization code. So only logs will be able to provide some clue after that. In HAR there is only a hint that there was a problem when exchanging authorization code for access token.

Also, could you share your Okta's configuration you created for Gluu? Screenshot, or whatever way convinient for you. I mean the settings at Okta itself, not client's properties in oxTrust.

Thank you for your answers and clear explanations Aliaksandr I'm starting to see more clearly the nuances of the configuration in Gluu. I'll attach in a moment all the details that you're asking for in another message. Regarding Okta I'll send you the details too but I'll look to use other flows too as you said that might be a problem there and is not a requirement to use it with the current one. Finally and a bit off topic, did you had the time to investigate the other ticket, regarding Office 365 integration? Because for us is more urgent than these integrations. Thanks again,

> That depends on what your client/RP requests from your Gluu Server (which scopes it sends in "scope=" url query parameter initially) - and what scopes your Gluu Server is ready to allow for this client as well (defined in its registration entry). Ok, I'll investigate that part for the current integrations. > Sorry, I probably wasn't clear enough: I meant the configuration on Moodle's side, not the client's properties from Gluu. In the original doc, at the end of it, there is part: "Configure Gluu in Moodle." Could you show me what is currently there? Sure, here the screenshots: https://www.dropbox.com/s/260fdlllikfcjwv/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-21%2016-44-05.png?dl=0 https://www.dropbox.com/s/j91ng0kp1tnm297/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-21%2016-44-20.png?dl=0 https://www.dropbox.com/s/964wpcr9kwbgod6/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-21%2016-44-40.png?dl=0 > I don't see any errors in your Moodle's HAR, so it seems like at least the OIDC flow itself succeeds. So, the issue is that you still don't see some user's attributes passed to Moodle? Correct? If so, which ones? I would take a look, the claims needed are Name, Surname and Email which are mandatory from Moodle side, so convenient to have them. > Still in process. The problem here is that it uses a regular code flow, so HAR won't show what happens next after flow is sent back to Okta's callback endpoint with authorization code. So only logs will be able to provide some clue after that. In HAR there is only a hint that there was a problem when exchanging authorization code for access token. Logs from your side were included in the previous message, here the link: https://www.dropbox.com/s/81ddxifasxaj8j7/oxauth-okta.log?dl=0 Regarding Okta's logs there aren't any detailed ones just logging attempts. > Also, could you share your Okta's configuration you created for Gluu? Screenshot, or whatever way convinient for you. I mean the settings at Okta itself, not client's properties in oxTrust. Configuration details: https://www.dropbox.com/s/8pzouzxy1psgfcf/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-25%2022-05-06.png?dl=0 Regarding Okta I'm seeing if other flows are less problematic but regardless I imagine that all flows should be usable with Gluu as it supports all standards

Hi, guys. What is the status of this issue? Has it been resolved, or you still need our help with it?

Hi Aliaksandr, For Moodle it's ok with your recommendations and adding the claims to access token, it seems that indeed they are not calling userinfo endpoint. For playgrounds I didn't investigate further but probably not worth it. Regarding Okta we still need help indeed as neither with implicit flow not with authentication code is it working.For the second case error is the same described above even testing with different config details and for the other is that response type is not support that IdP only supports id_token and token.

Hi. Sorry guys, just wanted to understand what should we do with this ticket. Do you still need our help with this?

Please feel free to update the ticket if you'll have more questions regarding this task.