I agree. Your app should never, ever be asking a user for their password. There is no good reason to do it; they have already signed in. Popping an authentication prompt adds no security whatsoever, and worse - if you are collecting this data yourself you open up new (and serious) security vulnerabilities you do not want to contend with. Check with your customer; maybe they'd be ok with just capturing a signature in a draw box along with the username and timestamp.
---
Now, for the sake of argument let's say that your customer doesn't want to listen to that argument and 100% insists that you MUST prompt for username and pass (again, I strongly discourage this, just offering a theoretical solution). In that case, you still do not want to handle the password yourself because it would actually be much LESS secure than never prompting at all. So here the only reasonable solution is to use a PCF and include the Active Directory Authentication Library (adal) to request a token from Active Directory. I have never had the need to request a token for a user that already has one, so this might require some weird workarounds (and I don't know what they'd be), but if you fuss with it enough you can probably figure out how to get AD to prompt the user for a name and pass even though they are already logged in, then return you a new validated token or failure. But here's the thing: you're taking on a big dev effort, using an authentication protocol in a way it wasn't designed to be used (therefore risking downstream complications), and at the end of all this your result is exactly the same: you're only going to capture a username and timestamp to prove the "signature" so why do it at all? It just makes no sense.
