Q:

Demystifying CSRF?

I've read through a lot of long explanations of CSRF and IIUC the core thing that enables the attack is cookie based identification of server sessions.  
So in other words if the browser (And note I'm specifically narrowing the scope to web browsers here) does not use a cookie based session key to identify the session on the server, then a CSRF attack cannot happen.  Did I understand this correctly? 
So for example suppose someone creates a link like:
 href="http://notsosecurebank.com/transfer.do?acct=AttackerA&amount;=$100">Read more!

You are tricked into clicking on this link while logged into http://notsosecurebank.com, however http://notsosecurebank.com does not use cookies to track your login session, and therefore the link does not do any harm since the request cannot be authenticated and just gets thrown in the garbage?
Assumptions

The OpenID Connect Server / OAuth Authorization server has been implemented correctly and will not send authentication redirects to any URL that you ask it to.
The attacker does not know the client id and client secret

Footnotes
The scenario I'm targeting in this question is the CSRF scenario most commonly talked about.  There are other scenarios that fit the CSRF tag.  These scenarios are highly unlikely, yet good to be aware of, and prepared for.  One of them has the following components:

1) The attacker is able to direct you to a bad client
2) The attacker owns that client
3) The attacker has the secret for that client registered with the OAuth Authorization Server
4) The attacker is able to tell the Authorization Server that authenticates you to redirect back to the bad client after you have been authenticated with the proper server.

So setting this up is a little bit like breaking into Fort Knox, but certainly good to be aware of.  For example OpenID Connect or OAuth Authorization Providers should most likely flag clients that register redirect URLs pointing to redirect URLs that other clients have also registered.

A:

The most common / usually discussed CSRF Cross Site Request Forgery scenario can only happen when the browser stores credentials (as a cookie or as basic authentication credentials).
OAuth2 implementations (client and authorization server) must be careful about CSRF attacks. CSRF attacks can happens on the client's redirection URI and on the authorization server. According to the specification (RFC 6749):

A CSRF attack against the client's redirection URI allows an attacker
     to inject its own authorization code or access token, which can
     result in the client using an access token associated with the
     attacker's protected resources rather than the victim's (e.g., save
     the victim's bank account information to a protected resource
     controlled by the attacker).
The client MUST implement CSRF protection for its redirection URI.
     This is typically accomplished by requiring any request sent to the
     redirection URI endpoint to include a value that binds the request to
     the user-agent's authenticated state (e.g., a hash of the session
     cookie used to authenticate the user-agent).  The client SHOULD
     utilize the "state" request parameter to deliver this value to the
     authorization server when making an authorization request.
[...]
A CSRF attack against the authorization server's authorization
     endpoint can result in an attacker obtaining end-user authorization
     for a malicious client without involving or alerting the end-user.
The authorization server MUST implement CSRF protection for its
     authorization endpoint and ensure that a malicious client cannot
     obtain authorization without the awareness and explicit consent of
     the resource owner

