The answer here is to strictly compare the Oauth2.0 rfc https://www.rfc-editor.org/rfc/rfc6749#section-4.1 Authorization code Grant terminology and flow with the implementation. Bear in mind that some security issues related to Oauth2.0 implementations are also mentioned in https://www.rfc-editor.org/rfc/rfc6819 with apropriate countermesures.
Seems to be a poor mans OAuth implementation of the Authorization Code Grant
There indeed seems to be some issues:
The Ressource ower is not clearly defined and/or confused with the User-agent
a) Logged in user clicks a link to access the 3rd party system
In Oauth2.0:
The client initiates the flow by directing the resource owner's
user-agent to the authorization endpoint. The client includes
its client identifier, requested scope, local state, and a
redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied).*
Here the client is the "3rd party", and the authorization endpoint "My application", if the "3rd party" is not issuing the client identifier, the scope and the local state to the browser, there is a high probability that the browser do the request with predefined params which is not what oauth2.0 was created for.
No state parameter so there's risk of XSRF
(C) Assuming the resource owner grants access, the authorization
server redirects the user-agent back to the client using the
redirection URI provided earlier (in the request or during
client registration). The redirection URI includes an
authorization code and any local state provided by the client
earlier.
CSRF could be mitigated with various techniques, but for that it is safer to follow oauth spec first and include a state parameter in the authorization request, since it SHOULD be used to protect against CSRF.
"3rd party" could be anyone
Not really, in a case where the local state is missing and the redirection URI incorrect, the the authorization server should not redirect the user agent back to the client. A security issue here could be that the authorization server allow multiple URI's origin.
Time to live on the code is a bit worrying
There's no way to expire the user's session in the 3rd Party application. In OAuth, the tokens usually expire after a while.
One problem in some cases with OAuth tokens is that they could be stolen by attackers, but it is mitigated by the fact that the expires_in parameter (in seconds) is added to the fragment component of the redirection URI.
Most of the time if this param is omited the authorization server do provide a default value. Here if the user session does not expire, you have to trust the 3rd party security to ensure that the session is not going to be stolen and usable.
