SoporteHT1 | 2018-12-13 17:42:14 UTC | #1
We are using a javascript integration, because, since the customer application they should make calls using a CTI function. The customer app have some buttons one to LOGIN, other to DIAL other to CLOSE, etc For this we using the loginImplicitGrant when the user enter at the APP an select the LOGIN button, thereby, the user is registered in purecloud. When he want to make a call, press the DIAL button and appear the Purecloud page for register again. Only. If, the user enter the credentials again he can make a call. The problems is that, the agent need entered the credentials 2 times for make calls.
tim.smith | 2018-12-13 17:51:19 UTC | #2
If you don't want users to have to log in every time, your app needs to remember their access token. The JavaScript SDK (for browser) has a setting to persist the token.
SoporteHT1 | 2018-12-13 22:11:51 UTC | #3
Thanks Tim We already enable settings persistence and is ok. Now we have other problem, After the login, on the redirect page in the URL field appear the application´s url followed the token or the simbol # For example: ** the original URL is: http://localhost:8082/PC/index.html
After the login, the url show: *Followed by the token http://localhost:8082/PC/index.html#accesstoken=DONTPOSTYOURACCESSTOKENPUBLICLY&expiresin=86399&token_type=bearer
*Followed by the # simbol, this case is when we refresh the page http://localhost:8082/PC/index.html#
Maybe have you some idea of this behavior?
tim.smith | 2018-12-13 22:19:13 UTC | #4
Please be sure not to post your access token publicly. Anyone who has it can access your org.
The # and everything after it is the URI fragment that contains the implicit grant authorization information. If you're using the SDK to handle authentication, it should be removing it from the URL automatically when loginImplicitGrant(...) is called. If you're handling the login redirects and processing manually, you can replicate how the SDK does it in your own code.
SoporteHT1 | 2018-12-14 21:22:17 UTC | #5
Thanks by the recommendation. But we can not solve the problem, Can you provide me more information, please?
tim.smith | 2018-12-14 21:26:56 UTC | #6
What is the problem you're facing? Your last post just described what sounds like expected behavior. If you can be precise about what you're observing vs. what you expect, that would be helpful.
SoporteHT1 | 2018-12-17 14:26:50 UTC | #7
Hi Tim When we using the implicit authentication function generate a reload of the page, with this, the orginal URL is changed and the data presented in the CRM´s screen is lost
tim.smith | 2018-12-17 15:39:27 UTC | #8
Yes, that's expected. Use the state parameter to pass a value with the login request that will be returned to you as part of the login response. The value can be any string. Your app can then use the value from the state param to initialize itself in any way you like. The JavaScript SDK documentation shows how to use the state param with the login helper.
SoporteHT1 | 2019-01-02 14:36:41 UTC | #9
Hi Tim, first I wish you a excelent new year! About my problem: We already test the state parameter with the login request but the problems continue we added one parameter in the call client.loginImplicitGrant (clientId, redirectUri, "state"))
However, when the user login the first time, the url is changed again with the respective token. But the next login the url persit, no change. The problem continue only with the first login I attach the screenshot of the page with the url changed after of login .
SoporteHT1 | 2019-01-02 14:37:10 UTC | #10
tim.smith | 2019-01-03 17:07:21 UTC | #11
Using the state parameter doesn't change the behavior of the login. But it gives you a value that you can get back as part of the login response. For example, you could send the current URI fragment in the state parameter then redirect the user to the URI you want, including the fragment from the state param, after the login completes.
SoporteHT1 | 2019-01-03 19:47:32 UTC | #12
The customer expectations with the page provider are that the page does n´t redirect or recharge it / refresh page. The needed is click over button Login and don´t reload the page only get a login successful and begins to do calls (and others interactions) in the same page.
What do you think is the best practice in this case. Thanks again for your time Tim!!!
tim.smith | 2019-01-03 20:05:15 UTC | #13
PureCloud uses OAuth 2.0 for Authorization. That documentation explains what that is and why we use it. The OAuth flow necessitates that the user be directed away from the custom application to the authorization provider to ensure that the user's credentials are handled safely. To put that plainly, the OAuth spec (implicit grant) doesn't trust the client application to handle the user's credentials, so it doesn't allow the client app to transmit them; the user must enter their credentials directly with the auth provider (PureCloud, in this case).
That doesn't hang you out to dry with regard to your app's experience though. If you handle the authentication process in the same window as your app, yes, you'll have a redirect away from your app. But if you implement a process to handle auth in a new tab/window/popup/iframe and can transmit the auth token back to the app securely, your app doesn't have to be unloaded for the auth process to happen in that new window. That process will either require a back-end service to handle getting the auth token from the login result page back to the main page of the app or some intra-page mode of communication (JS communicating across the iframe, for example).
Alternatively, your app could require a PureCloud auth token for it to initialize. So once a user signs in to your app, immediately redirect them to PureCloud for auth, if you need it, before loading your app. This would still have the redirects, but the user experience would be to sign into your app, then immediately be prompted to sign into PureCloud.
One last option is the SAML2 Bearer grant OAuth flow. However, this is only applicable if you're already using a 3rd party provider for SSO and isn't necessarily a good fit with all application architectures.
SoporteHT1 | 2019-01-07 14:14:22 UTC | #14
Hi Tim, please can you hel me with one example of SAML2 bearer grant thanks
tim.smith | 2019-01-07 16:45:14 UTC | #15
https://github.com/MyPureCloud/saml2bearer-oauth-example
SoporteHT1 | 2019-01-09 16:11:04 UTC | #16
Tim, thanks for your time. We trying to use ADFS URL inside index.html example. Is necessary some additional configuration in this case?
Original:
//var oktaUrl = 'https://inin.oktapreview.com/home/inindev351417_purecloud_2/0oa82726leSLOxkmG0h7/aln827p64sJb24Utt0h7';
Replace with this: var oktaUrl = 'https://adfs.ourdomain.com/adfs/ls'; $('body').append('<a href="' + oktaUrl + '">Log in with ADFS</a>');
tim.smith | 2019-01-09 18:02:57 UTC | #17
The process for implementing SAML2 auth with ADFS should be functionally the same, though I don't know, and wouldn't assume, that both Okta and Microsoft have implemented their SAML processes identically and are interchangeable in code. Getting an access token from PureCloud in your application should be the same regardless of the provider you choose integrate with.
I'd refer to the PureCloud ADFS SSO configuration and Microsoft's ADFS documentation for implementing a SAML2 Bearer integration in a custom application. There's also a previous thread about this that may have some useful information for you.
system | 2019-02-09 18:18:15 UTC | #18
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 4183