4

I'm trying to refresh an OAuth token using Lync UCWA, following the examples here, https://msdn.microsoft.com/en-us/library/office/dn356686.aspx#sectionSection3

The example in their docs uses grant_type urn:microsoft.rtc:anonmeeting, but I am using a grant_type=password. My client is successfully authenticating against the /WebTicket/oauthtoken endpoint at first and I receive the access_token just fine.

After a few hours, I need to refresh the OAuth token by posting to /WebTicket/oauthtoken again with the parameters of: 

grant_type=password
username=$my_username
password=$my_password
ms_rtc_renew=$access_token (cwt=AA....)

That is returning a status 400 though, with an error: invalid_request and a comment in the headers "No valid security token". The value I'm putting into ms_rtc_renew is the same value I'm using in all of my headers to other endpoints, 'Authorization' : ['Bearer $access_token'], so the token is working alright.

I have made sure that I'm using a header of Content-Type: application/x-www-form-urlencoded when posting to the /WebTicket/oauthtoken endpoint, and that I'm urlencoding the data before posting.

Has anyone else been able to refresh an OAuth token using Lync UCWA 1.0 and a grant_type=password? Any experienced UCWA devs out there recognize what I'm missing in my post to refresh the token?

Thanks in advance.

Kafonek
  • 362
  • 1
  • 2
  • 10

1 Answers1

5

ms_rtc_renew is specific to the anonymous meeting grant type. In that same documentation it mentions:

Refreshing a token for authenticated users is the same flow as acquiring a new token.

This is the correct train of thought, but it does omit a few key pieces of information. If you are interested in keeping the original UCWA application valid, it is necessary to provide the same information when executing the POST request on applications otherwise it will be creating a new application.

Expanded Answer

When you reach a point that the UCWA application is returning 404 to requests and indicating that the current OAuth token is invalid it is necessary to renew. Following the steps of KeyTasks-CreateApplication, request a new token on step #5. At this point take the new token and replace the Authorization header and attempt to make the failed request.

If that does not work, consider re-creating the application (step #9) using the same data (UserAgent, EndpointId, Culture). You would need to replace any saved Json data because the application Url might change between instances (not entirely certain).

ShelbyZ
  • 1,494
  • 1
  • 14
  • 32
  • Thanks for the reply ShelbyZ. Sorry I'm still not clear, is there a different key/value that UCWA is looking for when I try to renew a token that I got from using grant_type = password? Something like grant_type=password&username=johndoe&password=A3ddj3w&access_token=cwt... ? – Kafonek Apr 06 '15 at 17:44
  • 1
    Expanded my original fragment a bit, let me know if you that makes any sense. – ShelbyZ Apr 07 '15 at 13:43
  • Alright, so as far I understand it then, you're just suggesting that at the end of the 8 hours I should just create a new application instead of renewing the access_token I already have. That's a perfectly acceptable solution, but it seems to go against the spirit of the UCWA docs. No problem, it's UCWA 1.0 for a reason! – Kafonek Apr 07 '15 at 14:30
  • 1
    I think you are missing a key point that the non-anonymous grant types don't get the special renew parameter when requesting an OAuth token. The point being that the OAuth token expires and it _should_ be possible to request a new new one and replace the header and continue UCWA'n. The suggestion to create a new application would be in the case where the OAuth token expires and the application is also cleaned up. When you provide identical parameters upon creation the server should re-establish that application. – ShelbyZ Apr 07 '15 at 15:43
  • I'm tracking, ShelbyZ. The wording in the documentation is awkward, "The lifetime of a token is eight (8) hours for authenticated users. The client application should monitor the expiration time and refresh the token as required." I completely understand where you're coming from now, just need the documentation to read, 'the client application should request a new token when the original expires'. Thanks again for the clarification. – Kafonek Apr 07 '15 at 18:22
  • It is a bit confusing and the testing of it is much worse! – ShelbyZ Apr 07 '15 at 23:30